fde101

Ah...  sorry, somehow I missed that this thread was discussing Designer; I had assumed we were discussing Publisher, which uses pages, not artboards.  I believe most of the past discussion on the need for global layers has been in the context of Publisher.
I'm not surprised then (for Designer) that this method could appear to work while editing, but how does it handle exports?  I'll need to play with this when I get a chance - a bit concerned that some form(s) of exporting may leave out the objects that are on layers which are created this way, as they might not be considered part of the artboard...  would be happy to be wrong as I haven't tried this yet and am just guessing right now, but something to investigate before jumping the gun here.

That one will make a lot of people much happier.

That one will make a lot of people much happier.

@DJ!
I have tweaked fde101's reply as I think that was the problem, with the Mac beta ZIP from this post not being the one you need

That one will make a lot of people much happier.

I'm afraid I don't see what one of those has to do with the other.
The layers are still page-specific and not shared between pages.

Objects on such a layer that is not inside of any artboard are exported with the artboard's content. I just did a quick test, though.
d.

I've never seen evidence of that... I don't think anyone today knows what the original language was.  It may be that ALL of the languages changed and the original one has been long since forgotten.  A bit off topic for this forum, however.
 
This is kind of silly when you realize that several of the countries which are at war with or have been hostile toward Israel also have native languages which are right-to-left: Arabic is used for several of Egypt's languages and that is right-to-left; Arabic itself is the main language in Syria and is also commonly spoken in Palestine...
 
 
 
Don't forget top-to-bottom while you are at it.  Several languages are traditionally written that way.  Evidently there was at least one that was bottom-to-top as well, but that seems to be rather obscure by now.

JavaScript (more correctly called ECMAScript) is something I'm kind of learning out of necessity right now for a project I am working on which will run in a web browser.
It is unfortunate that yet another horrible language has become so entrenched in supposedly-modern applications that are designed to run in a web browser that it will be difficult if not impossible to get any kind of agreement on replacing it with something more legitimate.
One of the issues is that in spite of attempts over the years to "modernize" the language, it still has too strong a need to maintain compatibility with legacy code that was written in earlier, more primitive versions of the language that did things differently, so you wind up with some features using one approach to doing something, and others using a completely different approach to do almost exactly the same thing, but neither approach works in both places.  It is a language that has been haphazardly layered on top of itself by competing groups trying to pull it in different directions and the result is just a mess.
Couple that with the prevalent "C"-like syntax and it is not even remotely a fun language to work with, though admittedly there are a few interesting aspects to its design that are at least partially redeeming compared to other languages in the general "C-like" language family.  First-class functions and closures are a definite plus, and prototype-based inheritance makes it interesting from a theoretical standpoint anyway.
Never would I recommend further propagating it however.  We are kind of stuck with it for code that runs in a web browser, and I for one would prefer that it stay locked up in that cage until such time as we can replace it with something better there too.
 
For the record, I'm not the biggest fan of AppleScript as a language either, but it, like JavaScript, is the only real option in its domain right now for some use cases.

From the sound of things, each has different issues here - missing-refresh bugs in any case.

Yes, it's still Mac-only.

The Crop Tool does obey snapping, but only to the image boundaries or to guides, not to objects.
So one could draw a rectangle from the center (which is supported), then place guides (which would snap to the rectangle), and then crop by snapping to the guides. If one needs to crop from the center as a common part of their workflow that's too complex.

If you haven't already, you might want to try a demo of Capture One (https://www.captureone.com/) while you are waiting for Serif to introduce something in the Affinity lineup.  I believe it covers all of your requirements except the map view:
Not 100% certain how LR displays the images, but in C1 you can get a viewer with a filmstrip, a viewer with a grid of images, or a full-window browser with the viewer hidden.  You can set up separate workspaces with these arranged differently and switch between them if that is helpful. If you are using catalogs for organization, C1 even lets you browse cached previews of images from external/network drives while they are disconnected. When you need to send a photo from Capture One to Affinity Photo, use the "Edit With" option and the PSD file format.  If you enable the checkbox in Photo's preferences to save over PSD files, you can then edit the photo in Affinity Photo and save as usual (though saving a PSD takes longer than saving a native Affinity document) and the photo will be updated automatically in C1's catalog.  You can use "Open With" to later re-open that PSD in Affinity Photo without creating a new copy of it. For the most part it is (JPEG/TIFF/RAW), but there are some things that may only be relevant for RAW, and some that may only be possible when the model of camera/lens can be detected from the metadata in the file and are supported I'm not familiar with Alamy, but C1 supports keywords and can handle several interchange formats: https://support.captureone.com/hc/en-us/articles/360002544898-Metadata-in-XMP-files C1 supports a rating and a color tag There are a number of printing options, including profile selection and the use of user-created templates determining how the images are laid out on the page There is no map view in C1.  Evidently you can have it open Google Maps to the coordinates of the image, though I have never tried this myself as I consider the GPS data to be more of a hazard than a benefit and so have it disabled in the few cameras I own that support it: https://thedigitalstory.com/2016/08/capture-one-pro-geotags.html

From the discussions that I've seen over the past few years where Serif has participated, DAM functionality has always been presented as a separate application.

This is kind of interesting considering how many threads there are on the forum begging for and complaining about various formats that the Affinity programs do NOT currently support.

It sounds like you might actually be looking for perspective correction?
You might want to review this to see if it helps: 
 

I'm afraid I don't see what one of those has to do with the other.
The layers are still page-specific and not shared between pages.

Evidently that is a Windoze thing I wasn't even aware of.  Not all too common on the Mac, though it is used for renaming nodes in Fusion.
That said, it is probably as good of a shortcut for this as anything.

No, only the majority of the features of the Photo persona.  The Liquify, Develop, Tone Mapping and Export personas from Photo are not available directly within Publisher.
 
That said, the Photo persona covers a lot of ground.

Rulers are global...  guides are local to the artboard, or to the page in Publisher.  In Publisher you can put guides on a master page to make them available across multiple "normal" document pages which have the master page assigned to them, but Designer doesn't have an equivalent to that.  Note that as artboards can be different sizes, guides might not always match up between them in a meaningful way.

Hiding options within what essentially amounts to a list box when there is no technical advantage to doing so does not strike me as being a sensible idea.
I am firmly opposed to this one as it is suggested above - we would need an extra click to find those other options and would gain absolutely nothing from this.
 
If the concern is that the user is having trouble pinpointing one preset among the many, I would suggest instead adding a "favorites" feature so that specific templates could be flagged as favorites and show up in a separate "Favorites" tab - that tab might be broken down by the categories from the other pages and show only the favorite items underneath each one.

https://en.wikipedia.org/wiki/HSL_and_HSV
 
True... and that is very likely to happen any time photos are imported into a CMYK document as well.
 
That is probably a good idea...  though it might actually be a better fit for Publisher by being added to the Preflight panel.
 
Possibly, though HSL colors are not always 100% unique - it could also be that two different sets of numbers mapped to the same underlying RGB color value (as explained at the link above, HSL is built on RGB).
 
I believe that is basically how QuarkXPress works?
 
That is always a worthy goal, but note also that there was recently another thread where people were basically requesting the opposite.  They wanted the CMYK values of swatches to remain unchanged when pasting something into a document with a different color space - they were more concerned about the numbers than the actual color for some reason related to corporate standards of clients or some such.  I can see that with the K value (for blacks) if there is a desire to conserve more expensive color ink when writing out body text, and while I personally still think it would typically be better to educate those clients, there are obviously multiple factors to be considered.

I understand now. I think in a usual set up it will make the most sense to click on tab and see the long list of the tab you clicked on. Having the first row be recents would probably be fine. I don't think the short list of all the sections would work as well.

There should really be an option for the text frame itself to apply the baseline grid to only the first line in the frame.

I was originally going by the mockup you provided in your OP - you show four entries and a "more" button on each tab, and that I would be strongly opposed to.  Clicking the tab should be enough to show all of the options.
Adding a "most recently used" section to the top then showing all of the options underneath it would be fine, maybe something like this:

Having the tabs and the "more" button though is just an extra click to reveal them which would be pointless and you would be wasting all of the remaining space there until the button was clicked.
If the idea was to get rid of the tabs and show the sections as separate headers instead, then I could see that scheme working, but personally I would still prefer the current approach.