fde101

The truly unfortunate thing here is that while Publisher (Fields panel) and Photo (Metadata panel) both provide different limited versions of this already, they have only partial overlap in terms of the fields that are accessible, and neither application currently supports custom fields.
I agree that this should be standardized, support for custom fields added, and the feature provided across the product line.

In existing professional DTP applications such as QuarkXPress and InDesign, ALL layers are global layers, with any per-spread or per-master content being nested within them.  This is how it has been for several decades now and I have never seen complaints by their users that they do not have the option of limiting a given layer to a particular page.  That is not a description of how it needs to be in the Affinity apps, it is the reality of what already exists in other apps which professionals have been using for a long time, and it works.
As to whether or not the Affinity apps should behave that way, that may be an open question, but consider what could happen if they do not.
Assume there are three global layers, Front, Middle and Back.  As these are global, they appear on every spread and every master.
Now on a single spread of the document, call it spread 2, you add a spread-specific layer between Middle and Back, I will call it Local for purposes of this example.
Now we have spread 1 with layers Front, Middle and Back, and spread 2 with layers Front, Middle, Local and Back.
An important point possibly not mentioned until now is that the ordering of global layers is also shared among all spreads (at least, in existing apps).
What happens if I am working on spread 1 and decide to move layer Middle behind layer Back - what happens to Local on spread 2?  Does it move along with Middle, presumably because it was meant to contain content that should be behind the layer you are moving, or does it stay between Front and Back, presumably because it is meant to contain content that was intended to be in front of Back?  The movement of the global layer from spread 1 is ambiguous regarding the content of the layer on spread 2, because it is not visible in the layers panel and there is no way for the user to express that intent.
Let's assume for a moment that the software were implemented this way and the Local layer remained in front of Back, causing spread 2 to contain Front, Local, Back, Middle.
Now the user decided that Middle should have been where it was to begin with and moves it back.  On spread 1, the user only sees Front, Back, Middle, but for spread 2, the software need to decide if Middle is being moved before Back or after Front - in other words, it is again ambiguous as if the layer is being moved before Back, then you could wind up with Front, Local, Middle, Back.  Because the user has been working on spread 1, it might go unnoticed at this point that by manually "undoing" the move of Middle behind Back, the Local layer on spread 2 has in effect migrated from being behind Middle, to being in front of Middle.
Multiply this confusion across hundreds of spreads each of which may have "local" layers with different intentions, and you might start to realize why this is a bad idea - seemingly simple manipulations of the layer stack could wreak havoc on the structure of the rest of the document, and it would go unnoticed while you were focusing on just one place.
One way to resolve this would be to have the order of global layers independent for each spread - then if you wanted to move Middle behind Back it would only impact the spread you are on, but what happens when you actually WANT the layer to move on all spreads?  If you have hundreds of spreads, you need to go through and make that change on every one of them (and on the masters), which reduces the benefits of having used global layers in the first place.
These same issues occur for layers which are shared among some spreads but which are not present on all of them - the same issues would occur.
If you want a mix of top-level layers being both global and local (and possibly shared among some but not all spreads), this is the sort of problem that the intended behavior needs to be defined for.  Something needs to give at some level - there needs to be compromise of some sort, which is largely why I think @TonyB started asking those questions to begin with - to determine what kind of compromises people are willing to live with.
 
Consider just three of the many possibilities here, just with the points I raised in this post:
All top-level layers are global if any global layers are used, and the order of layers is shared among all spreads and masters.  In this case, there is no ambiguity when re-ordering layers, and document-wide changes can be made quickly and easily.  On the downside, a few of the global layers might not be used on every spread, so there might be a handful of extra layers cluttering the interface for the most complex documents. Possible improvement: a toggle is added to the layers panel to hide global layers which have no content on the specific spread or master, except when moving global layers.  This reduces the clutter under normal conditions, but needs to be turned off when first adding content to one of the hidden layers; making them visible when re-ordering the layers helps to eliminate the ambiguity of what to do with the others, but also means that the place you are dragging to in the layers panel becomes a moving target compared to when you started the dragging action. Top-level layers may be a mix of global, shared (subset of spreads) and local (per-spread) layers, including individual object layers; the order of global layers is shared among all spreads and masters, and the order of shared layers is shared among those spreads which contain them.  In this case, the number of irrelevant layers which appears in the layers panel is reduced, but moving layers which are global or shared can have unexpected consequences for other spreads of the document which may not be immediately noticed by the user. Top-level layers may be a mix of global, shared (subset of spreads) and local (per-spread) layers, including individual object layers; the order of global and shared layers is unique to each spread and master.  In this case, the number of irrelevant layers which appears in the layers panel is reduced, and moving any top-level layers on one spread will not impact other spreads at all.  To make changes to the layering structure of the contents of different global layers throughout the document, the layers must be manually re-ordered separately for each spread, even if there are hundreds of spreads. The need to manually re-order layers across many spreads can be alleviated by a menu command that opens a dialog box to express the exact operation desired.  This could allow specification of which layer(s) to move, where to place them (after layer X, before layer X, at the bottom of the layer stack, at the top of the layer stack, etc.), and which spreads to include in the change.  However, this would still be more work than simply having them all share a common layer order to begin with, and still cannot accurately express every possible scenario when dealing with layers that are not present on all spreads.  
Consider which of these (or some other behavior) would be most appropriate for your work, then try to consider people working on different types of projects, and realize that the one you pick will still cause problems for someone else.
My argument is that the well-defined behavior of all top-level layers being global and having a shared order among all spreads and masters, something which already exists in the wild and is well-understood in other apps, is the least problematic solution of any I personally can think of for the greatest range of users with the widest assortment of projects.  By all means, discuss other options if I missed something (as I am quite sure that I have).

You can do this already:
Right-click on the master page layer in the Layers studio and select "Edit Detached".
You should also find this option on the context toolbar when the move tool is selected and no layers are selected on the page.

If you are doing a lot of this you might be better served with artboards in Designer rather than with pages in Publisher as they can be named and can be of differing sizes (if you have a use for that) and the Export persona defaults to taking the file names from the names of the artboards.  It can also export multiple formats and/or resolutions in one go if you need that.

This is a classic Mac behavior for floating palettes, toolboxes and the like.  I believe it is because such windows need to float on top of other windows, and if you switch applications, where the floating palettes would not be useful, it is not desirable for those palettes to float on top of the windows for that application too - so they simply get hidden when you are working in a different application.
I agree that there are times when this can be annoying, but I attribute that primarily to application designers abusing this type of floating window for things it wasn't originally intended for.  When used for things like the studio panels I don't really see this as being a problem - just something you get used to - but sometimes I have seen applications use them for things like content or memo editors, and if you are displaying content that you want to reference when you switch to another application, it disappears, so that is much more of an annoyance.

The truly unfortunate thing here is that while Publisher (Fields panel) and Photo (Metadata panel) both provide different limited versions of this already, they have only partial overlap in terms of the fields that are accessible, and neither application currently supports custom fields.
I agree that this should be standardized, support for custom fields added, and the feature provided across the product line.

The truly unfortunate thing here is that while Publisher (Fields panel) and Photo (Metadata panel) both provide different limited versions of this already, they have only partial overlap in terms of the fields that are accessible, and neither application currently supports custom fields.
I agree that this should be standardized, support for custom fields added, and the feature provided across the product line.

Scale with object is a property of individual objects, not a setting for the tool, so its state travels with the objects themselves and cannot be a global setting.
Newly created objects generally take on the value most recently manually set, so if you set it on the first object you create in a document, it should carry forward from there as long as you don't turn it off.
For existing documents, try select all then update the setting.

Yes, and those of us who have been around on the forums (or who actually take the time to read the online help) know that, but someone who randomly stumbles on the program on one of the various app stores (or the Serif web site) might not be expecting to need to do that.  If they create documents which are then made public it has the potential to make their name publicly available in a manner they might not have anticipated, and depending on the nature of the material and its distribution, that can sometimes be a bad thing.

Object styles should really work more like character styles: you should be able to turn on and off individual aspects of the "formatting" (styling) and the objects should be linked back to the styles so that if you update the style the objects automatically follow suit.
 
That said, this has also been discussed in other threads.

That would be a wasted email until Serif offers a plugin API or SDK of some kind.

They still rely on the 3rd-party app to do it though (the one from the chart manufacturer); it would be much nicer to have it in-app the way it is in Resolve.

This is a duplicate of a long-standing request in another quite lengthy thread which is pinned at the top of the Publisher section: 
 

Command+Shift+H on a Mac.
 
This is the same on the Mac.

Having the lock show up only on layers that actually are locked makes it easier to distinguish at a glance than trying to pick out a locked lock from a nest of unlocked ones.  It stands out better this way.

Welcome to PagePlus 3. Yes, I still have them in a virtual machine! Note the toolbox changes, amongst other things, when going from Intro to Professional.


 

SQL is a domain-specific language that does not really belong in a comparison with the others.  It is like comparing the popularity of apples, oranges and Japanese.  That alone likely skews the results to the point of being less meaningful than a proper comparison.
Ignoring that I do find it to be a sad reflection on the state of our culture that so many programmers today tend to favor some of the worst programming languages in existence that none of the more reasonable ones (except SQL which again doesn't really fit with the others) even make it into the lists.  People are in so much of a hurry to produce fast sloppy coding with cryptic syntax that no one is taking the time to produce solid, readable code.

If people are holding off on switching to Linux from other platforms because of some perceived lack of software options, then providing them with those options would make it easier for them to switch.  Once they are switched to Linux, they would have no reason to buy future versions of Serif products if those products are not available on their platform of choice.

It would require much more than that.

Dropbox provides an API which includes functionality such as file locking and custom properties, so it may theoretically be possible to build on those features to make this possible, but it probably wouldn't be optimal, and it would still be a lot of work either way.
Short version, I don't disagree that there would be use cases for this, but I don't really see Serif devoting resources to it until some of the other requests (global layers, tracing bitmaps to vectors in Designer, "free transform", etc.) have been addressed.

Most likely because for some inexplicable reason Serif decided to omit their imposition functionality when exporting.  It is only available when printing.
This additionally has the rather unfortunate side-effect of also preventing the imposition functionality from working if you need to export in CMYK, as they also only provide printing in RGB.
In short, if you need CMYK output, you need to use a separate imposition tool, even if the internal functionality would otherwise cover it.
If RGB output is OK and the limited set of options provided within the software meets your requirements, you can print to a PDF, either through the convenient "PDF" button on the Mac print dialog, or through a PDF printer on that other platform (as pictured in the OP).

I regularly use Create Booklet 2 for our in-house printing needs. It is available on the Mac App Store. Here is the website of the developer: https://www.thekeptpromise.com/CreateBooklet/

A somewhat unusual, but not particularly unwelcome request.
 
I don't think this one is going to be practical.  Dragging a placed image will generally cause it to be transformed (moved), and it is perfectly valid for images to overlap on the page.
 
Yes, this totally would be.

I don't see Capture One Pro mentioned here, that is one of the really big players in this field.  Another one that is out there is Exposure (from Exposure Software).

That might be fine for your purposes, but if in general, then you are missing something.
Consider that in a given book there can be different kinds of pages: a page with all text, one with an image in the top half and text at the bottom, a special chapter title format, etc.
You might have several common masters reflecting different layouts, but in a book which is translated, you might have five different languages (for example) and each master might have one or more text frames on a separate layer for each language.
If you have an English layer and a Klingon layer (random language choices) on each of three or four masters, you could toggle the layers within the masters to show or hide each language, but you would have to go through and do it separately for each master, then you still wouldn't catch page-specific objects which are not on the master page(s).
With global layers, you could toggle the visibility for a language across ALL masters and pages in ONE STEP by having them all on a common layer.
The ability to have multiple masters assigned to a single page is interesting, but it does absolutely nothing to help with this problem.