Medical Officer Bones

This is anecdotal. In two decades of working with web/graphic/screen/game designers and developers (both Europe and North America) and teaching thousands of students from all over the globe, I perhaps saw a handful of Linux users. In the past five years I haven't encountered any student in a digital design related program using Linux.
It's either Mac or Windows for the by far majority of these type of users, simple as that. Young design students just do not see Linux as an alternative. I have had trouble enough to get them to try open source alternatives like Krita!
That's not saying I would not like to see Adobe and Affinity release their software on Linux, far from that. I think if they would, Linux would become a more attractive choice for a certain sub-set of designers. I would make the switch, for example. But the fact is, no-one I've ever met and worked with in graphic/screen/mobile/web design related fields worked with the Linux platform. And I myself am very much the exception: barring one or two people, I haven't spoken to any designers who would even consider the switch to Linux (most don't even know what "Linux" is!).
I agree it's a bit of the chicken and the egg problem. But that doesn't take away the issue that the Linux desktop space is tiny compared to Windows and Mac, and the fact that the desktop/laptop design folks prefer Mac and Windows. Or that the Linux desktop space is so terribly fragmented. Even Linus admitted last year (more or less) that Linux as a desktop platform is its own worst enemy because of the fragmentation. As has been mentioned earlier in this thread, it would make more sense to invest in a ChromeOS version.
Linux in various shapes and forms is super-wide adopted all over the world in many situations, far more than either Windows or Mac; except for mainstream desktop users and certainly not in the world of graphic/web/general design.
Tiny adoption rate as a platform & tiny subset of target users  = no hope in heck to earn back your investment over a semi-long term.

Yes, of course, I was merely quoting Krita as an example to explain that even if Affinity would become available on Linux, it wouldn't convince many users to Linux. Only a handful compared. People like SrPx and myself, perhaps, but of all the designers and students who I encountered throughout the years? Hardly anyone.
That would probably include myself The question is whether this tiny fragment of users would be sufficient to make it worthwhile for Affinity or Adobe? No.
Of course it is subjective! And that very subjectivity prevented other "better" or more advanced technologies to gain the upper hand in the market before. Mac is the preferred choice, for many historical reasons, subjective reasons, and emotional reasons, and so on, and so forth.
Unless something dramatic occurs, humans are incredibly inert to overall change, self-oriented, and tend to be (very) short-term bi-polar minded thinkers. To the point of destroying their fragile little planet.
Which explains why Mac, Windows, and Linux users often find themselves in a scuffle over something so inane as which OS is "the best". Utter waste of time and energy, of course, but that seems to be the human condition rearing its ugly head again and again, to the detriment of humanity.
Perhaps. I think it is more complicated than that, and far more factors are involved, and not a black-and-white situation (nothing ever is: it is human nature to turn things into a yes-no thing). I highly doubt the impact of releasing Affinity on Linux would make even a noticeable dent on Linux as an OS of choice for designers. Like @SrPx stated in an earlier post, the issues run deeper than that.
This is not a matter of simple "chicken or the egg".  If that were so, someone would have released a successful high level design application on Linux by now.

@SrPx Your experience is identical to mine. I tried to switch friends and family to Linux, mainly because the only tasks involved were web browsing and a spot of text processing. Almost no-one liked it, and asked for Windows or Mac after a while. The sole exception is my wife, who works on a simple laptop which used to run WIndows 10, and now runs Linux Mint. But the only reason she continues to use it, is because I am always there to help her out with technical issues and updates. Without me, she wouldn't know, and prefer Windows (even though it runs much slower on that machine).
The one thing I HAVE been successful in convincing others to switch to: LibreOffice, Blender, and Krita. I actually got an entire college to adopt Blender for general 3d work, and so far almost every friend or family member is no running LibreOffice, without issues. And Krita has been adopted by various students as well.
But as I stated earlier, and SrPx points out as well, software is only a tiny factor in choosing a desktop platform, or a mobile platform It does indeed run deeper.

@SrPx Your experience is identical to mine. I tried to switch friends and family to Linux, mainly because the only tasks involved were web browsing and a spot of text processing. Almost no-one liked it, and asked for Windows or Mac after a while. The sole exception is my wife, who works on a simple laptop which used to run WIndows 10, and now runs Linux Mint. But the only reason she continues to use it, is because I am always there to help her out with technical issues and updates. Without me, she wouldn't know, and prefer Windows (even though it runs much slower on that machine).
The one thing I HAVE been successful in convincing others to switch to: LibreOffice, Blender, and Krita. I actually got an entire college to adopt Blender for general 3d work, and so far almost every friend or family member is no running LibreOffice, without issues. And Krita has been adopted by various students as well.
But as I stated earlier, and SrPx points out as well, software is only a tiny factor in choosing a desktop platform, or a mobile platform It does indeed run deeper.

For you and me, yes. As I said earlier, I view myself (and, based on posts written by you and seeing your experience) you as exceptions. I haven't met many designers willing to be so open-minded about switching when certain software would be available on Linux. It generally isn't that simple.

Based on the lastest Publisher beta, as far as I can tell no method to lock guides is available.
Here is why the current guides and columns implementation is a rather misguided one (pun intended
First, let's list @R C-R's objections to a guide lock feature:
perform many different tasks with the move tool based on canvas position; accidents are more likely &  this workflow requires more care, but works faster than otherwise would be possible; avoids the need to open a menu or click a button to lock guides (extra work), and vice versa no need to deactivate a guide lock (less work) and prevents me from being unable to work with existing guides. adds interface/workflow clutter, making goofs more likely what would prevent the user from accidentally push a lock guides button? A lock guides button is just as prone to accidental mistakes as, for example, the layer lock button. the current visual cues and hints are more than enough to warn the user and prevent the user from accidentally moving guides with the move tool adding this lock guides feature may result in endless amounts of 'goof proofing' (because preventing any sort of accidental change would require this: where does one stop?) the user is just as prone to accidentally move a canvas guide, as they are mistakenly clicking a lock guides button Next, let's assume we work with a simple magazine-type layout template, consisting of multiple grids (and I would like to emphasize that this is a very simple grid-based layout). As anyone even remotely familiar with layout design is aware of, good layout grid controls are a basic ingredient):

Now, before I discuss @R C-R points, this already highlights one of the issues we encounter with Publisher's "innovative" new columns approach: only ONE (1) column grid may be defined per master page (or per page). In page layout design more often than not multiple page grids and sub-grids are defined on any one page and/or page template.
I solved it here by first creating a 12-column grid, then placing guides, and then create a four-column grid. That's as far as I can go: if I want to create another 8-column grid at the top third of the page, or a sub-grid to define image positioning on the right of the text columns, and another one on the left, I encounter several challenges in Affinity Publisher:
The space/layer in which guides live is a "special" guide layer. Only one (1) set of guides can be defined on this "guide plane". It is impossible to create multiple guide sets. It's either all guides, or none that are visible. [2] would be somewhat workable if guide presets could be saved. They cannot, so it is not possible to quickly switch between guide sets. Guides do not really behave like other objects. For example, it is not possible to select multiple guides, and move these simultaneously. These issues are prevented in other design applications (such as InDesign) by basically treating guides as more or less regular objects. Guides can be placed in any layer. Multiple guide sets can easily be managed with multiple layers.
So what about that snazzy novel Column Guides approach in Publisher? As far as I can tell, it is a work-around to provide a solution for Affinity's limitation that only one set of guides can be defined on the "guide plane". At first glance, it seems like a pretty attractive solution: it is non-destructive, and separating the guides plane from this new grid plane solves the immediate "only one set of guides" limit. And those visually attractive solid columns provide for some nice eye candy in Affinity promotional videos!
But examining this from a workflow point of view, it only exacerbates the entire page layout grid and guides workflow: 
still only one guide set possible at any time per page or master page still only one page grid possible at any time per page or page master to work with multiple page grids, the user must create additional master pages, a less than desirable and convoluted workflow taking much more time a quick temporary grid just can't be done without destroying either the guides or overriding the master page's column settings. it is not possible to create guide systems based on selections. In a sense, Affinity Publisher new Column Guides, being separated from the guides, are really sort-of attempting to find a solution for a problem that never existed, if multiple guide layer/sets would be possible on the same page or master page.
To say that 1 guide set and 1 column/row page grid are enough in page layout design is... Well, it is madness, and displays a complete lack of understanding how layout (semi)professionals work, in my opinion.
The sensible solution would be to either introduce groups in the layer guide manager, and allow these to be individually activated and deactivated on demand, or just drop the current approach, and implement guides as objects which can be used in layers.
 
Anyway, let's return to the topic at hand: the option to lock guides and @R C-R's list of objections to having such an option.
Even the above 12-column grid is a simple and commonly used one. Publications may go up to double that, btw, and introduce many subgrids in InDesign for various things.
Users tend to move things by grabbing the center of the object. In particular when a cross is displayed (check the image objects) a user's eyes will be focused on the center, and they will start dragging from that point. Because two guides are positioned near the center of these images, it becomes exponentially more common for a user to accidentally drag one of the guides, instead of an image object. This immediately is a counter-argument to points [2], [6], and [8]: users will not carefully position their mouse cursors and wait for a visual cursor hint to pop up and then move the object. Users do not wish to or will not second-guess this type of drag and move action: it is kinetic memory at work here, and a user expects the object to move when they move the mouse cursor on top of an object. The focus of the action is the image boxes, not the guides. 
(within this context it is interesting to note that this is related to the selective attention test behaviour and the famous invisible gorilla experiment: humans focus on what is important to them, not on secondary fluff - in this case, guides are not important to think about or focus on).
The result is predictable: users WILL grab those guides by accident OFTEN. They can't help themselves, and they are not to blame: that is just how users visual systems and cognition works. This is why a lock feature is absolutely essential, and why any other design application in the market includes one.
It also means FAR more work to correct mistakes, and this is a counter-argument to point [2]'s assertion that without a guide lock option a user would work faster than otherwise possible. It depends on the situation, of course, but in complex page layouts with many guides this is obviously not true. Even handling a simple page layout with a couple of guides which happen to be close to the center of objects create many more accidental mistakes than expected.
Points [4], [5], [8]: As long as the guide lock option is hidden in a meaningful place in the GUI, accidentally turning it on (or off) becomes nigh-on impossible. For example:

To lock layers would take a number of conscious steps: Open the menu. Navigate to the Guides menu option. Click. Navigate to the Lock Layers option. Click. Close the window. Too many steps to "goof up" accidentally. Or at least, not very likely. That said, an unsuspecting novice user might find it troublesome to discover guides in a document sent to them cannot be re-positioned. My opinion is that this negative user scenario does not outweigh the positives of a guide lock option for the far majority of users and user scenarios, as proven by other design applications.
As for [4]: We must distinguish between GUI clutter and workflow clutter/inefficiencies. Yes, it does add one more checkbox. Does it clutter the GUI in the above example? I don't think so. It feels like a logical addition. As for the workflow with guides, it would be improved, as already stated.
Besides, novice and low-level users wouldn't even notice this option, because they would probably hardly open this dialog (excepting the user scenario mentioned earlier). Which means nothing essential is lost in either GUI or workflow, and important control over workflow is gained.
[1] [perform many different tasks with the move tool based on canvas position]: nothing would change in this regard if a guide lock feature is implemented. Indeed, it would simplify working with this tool and having many layout elements with a large number of guides. Currently, the only option to prevent accidental guide repositioning in a document with many guides is to switch to the node tool. But the node tool hides text boxes, and cannot be used to move vector objects (other than the "live" vector objects, which is an inconsistency if you think about it).
In short, without a guide lock option the user may actually be forced to use the node tool.
[7] [adding this lock feature may result in endless goof proofing - where does one stop?] No-one in this discussion asked for more than a simple guide locking feature. And I think I have disproved your assertion that a guide lock option would be "goof proofing": instead, it is an expected and common useful addition to assist in complex layout design control. A layer lock option achieves the opposite: it improves the usability of Affinity as layout design software.
Conclusion: a simple guide lock option solves many workflow issues related to Affinity's three apps when dealing with more complex and controlled layouts. Even in relatively simple layout design guides may be accidentally selected instead of the content, depending on the visual status of the document. It also wouldn't increase either GUI clutter or cause an inefficient or confused workflow - rather the opposite.
Aside from this, in my opinion the Affinity Publisher devs are attempting to find a solution for a core issue in all their applications: the single-layered guide plane. The current columns solution works okay for simple layouting, but is merely a work-around for not having to deal with that core issue. My opinion, of course. I am sure many Publisher users will laud this as the most innovative thing ever to be seen in a publishing application. In the meantime InDesign runs circles around Publisher for complex page layout design controls.
[apologies for this rather long piece :-) ]

Based on the lastest Publisher beta, as far as I can tell no method to lock guides is available.
Here is why the current guides and columns implementation is a rather misguided one (pun intended
First, let's list @R C-R's objections to a guide lock feature:
perform many different tasks with the move tool based on canvas position; accidents are more likely &  this workflow requires more care, but works faster than otherwise would be possible; avoids the need to open a menu or click a button to lock guides (extra work), and vice versa no need to deactivate a guide lock (less work) and prevents me from being unable to work with existing guides. adds interface/workflow clutter, making goofs more likely what would prevent the user from accidentally push a lock guides button? A lock guides button is just as prone to accidental mistakes as, for example, the layer lock button. the current visual cues and hints are more than enough to warn the user and prevent the user from accidentally moving guides with the move tool adding this lock guides feature may result in endless amounts of 'goof proofing' (because preventing any sort of accidental change would require this: where does one stop?) the user is just as prone to accidentally move a canvas guide, as they are mistakenly clicking a lock guides button Next, let's assume we work with a simple magazine-type layout template, consisting of multiple grids (and I would like to emphasize that this is a very simple grid-based layout). As anyone even remotely familiar with layout design is aware of, good layout grid controls are a basic ingredient):

Now, before I discuss @R C-R points, this already highlights one of the issues we encounter with Publisher's "innovative" new columns approach: only ONE (1) column grid may be defined per master page (or per page). In page layout design more often than not multiple page grids and sub-grids are defined on any one page and/or page template.
I solved it here by first creating a 12-column grid, then placing guides, and then create a four-column grid. That's as far as I can go: if I want to create another 8-column grid at the top third of the page, or a sub-grid to define image positioning on the right of the text columns, and another one on the left, I encounter several challenges in Affinity Publisher:
The space/layer in which guides live is a "special" guide layer. Only one (1) set of guides can be defined on this "guide plane". It is impossible to create multiple guide sets. It's either all guides, or none that are visible. [2] would be somewhat workable if guide presets could be saved. They cannot, so it is not possible to quickly switch between guide sets. Guides do not really behave like other objects. For example, it is not possible to select multiple guides, and move these simultaneously. These issues are prevented in other design applications (such as InDesign) by basically treating guides as more or less regular objects. Guides can be placed in any layer. Multiple guide sets can easily be managed with multiple layers.
So what about that snazzy novel Column Guides approach in Publisher? As far as I can tell, it is a work-around to provide a solution for Affinity's limitation that only one set of guides can be defined on the "guide plane". At first glance, it seems like a pretty attractive solution: it is non-destructive, and separating the guides plane from this new grid plane solves the immediate "only one set of guides" limit. And those visually attractive solid columns provide for some nice eye candy in Affinity promotional videos!
But examining this from a workflow point of view, it only exacerbates the entire page layout grid and guides workflow: 
still only one guide set possible at any time per page or master page still only one page grid possible at any time per page or page master to work with multiple page grids, the user must create additional master pages, a less than desirable and convoluted workflow taking much more time a quick temporary grid just can't be done without destroying either the guides or overriding the master page's column settings. it is not possible to create guide systems based on selections. In a sense, Affinity Publisher new Column Guides, being separated from the guides, are really sort-of attempting to find a solution for a problem that never existed, if multiple guide layer/sets would be possible on the same page or master page.
To say that 1 guide set and 1 column/row page grid are enough in page layout design is... Well, it is madness, and displays a complete lack of understanding how layout (semi)professionals work, in my opinion.
The sensible solution would be to either introduce groups in the layer guide manager, and allow these to be individually activated and deactivated on demand, or just drop the current approach, and implement guides as objects which can be used in layers.
 
Anyway, let's return to the topic at hand: the option to lock guides and @R C-R's list of objections to having such an option.
Even the above 12-column grid is a simple and commonly used one. Publications may go up to double that, btw, and introduce many subgrids in InDesign for various things.
Users tend to move things by grabbing the center of the object. In particular when a cross is displayed (check the image objects) a user's eyes will be focused on the center, and they will start dragging from that point. Because two guides are positioned near the center of these images, it becomes exponentially more common for a user to accidentally drag one of the guides, instead of an image object. This immediately is a counter-argument to points [2], [6], and [8]: users will not carefully position their mouse cursors and wait for a visual cursor hint to pop up and then move the object. Users do not wish to or will not second-guess this type of drag and move action: it is kinetic memory at work here, and a user expects the object to move when they move the mouse cursor on top of an object. The focus of the action is the image boxes, not the guides. 
(within this context it is interesting to note that this is related to the selective attention test behaviour and the famous invisible gorilla experiment: humans focus on what is important to them, not on secondary fluff - in this case, guides are not important to think about or focus on).
The result is predictable: users WILL grab those guides by accident OFTEN. They can't help themselves, and they are not to blame: that is just how users visual systems and cognition works. This is why a lock feature is absolutely essential, and why any other design application in the market includes one.
It also means FAR more work to correct mistakes, and this is a counter-argument to point [2]'s assertion that without a guide lock option a user would work faster than otherwise possible. It depends on the situation, of course, but in complex page layouts with many guides this is obviously not true. Even handling a simple page layout with a couple of guides which happen to be close to the center of objects create many more accidental mistakes than expected.
Points [4], [5], [8]: As long as the guide lock option is hidden in a meaningful place in the GUI, accidentally turning it on (or off) becomes nigh-on impossible. For example:

To lock layers would take a number of conscious steps: Open the menu. Navigate to the Guides menu option. Click. Navigate to the Lock Layers option. Click. Close the window. Too many steps to "goof up" accidentally. Or at least, not very likely. That said, an unsuspecting novice user might find it troublesome to discover guides in a document sent to them cannot be re-positioned. My opinion is that this negative user scenario does not outweigh the positives of a guide lock option for the far majority of users and user scenarios, as proven by other design applications.
As for [4]: We must distinguish between GUI clutter and workflow clutter/inefficiencies. Yes, it does add one more checkbox. Does it clutter the GUI in the above example? I don't think so. It feels like a logical addition. As for the workflow with guides, it would be improved, as already stated.
Besides, novice and low-level users wouldn't even notice this option, because they would probably hardly open this dialog (excepting the user scenario mentioned earlier). Which means nothing essential is lost in either GUI or workflow, and important control over workflow is gained.
[1] [perform many different tasks with the move tool based on canvas position]: nothing would change in this regard if a guide lock feature is implemented. Indeed, it would simplify working with this tool and having many layout elements with a large number of guides. Currently, the only option to prevent accidental guide repositioning in a document with many guides is to switch to the node tool. But the node tool hides text boxes, and cannot be used to move vector objects (other than the "live" vector objects, which is an inconsistency if you think about it).
In short, without a guide lock option the user may actually be forced to use the node tool.
[7] [adding this lock feature may result in endless goof proofing - where does one stop?] No-one in this discussion asked for more than a simple guide locking feature. And I think I have disproved your assertion that a guide lock option would be "goof proofing": instead, it is an expected and common useful addition to assist in complex layout design control. A layer lock option achieves the opposite: it improves the usability of Affinity as layout design software.
Conclusion: a simple guide lock option solves many workflow issues related to Affinity's three apps when dealing with more complex and controlled layouts. Even in relatively simple layout design guides may be accidentally selected instead of the content, depending on the visual status of the document. It also wouldn't increase either GUI clutter or cause an inefficient or confused workflow - rather the opposite.
Aside from this, in my opinion the Affinity Publisher devs are attempting to find a solution for a core issue in all their applications: the single-layered guide plane. The current columns solution works okay for simple layouting, but is merely a work-around for not having to deal with that core issue. My opinion, of course. I am sure many Publisher users will laud this as the most innovative thing ever to be seen in a publishing application. In the meantime InDesign runs circles around Publisher for complex page layout design controls.
[apologies for this rather long piece :-) ]

callas pdfToolbox is the only other pdf application that can do separation preview and is color managed. callas is who licenses to Adobe much of what Acrobat does. The one thing it doesn't do is edit text in a pdf.

If you are on Windows, the best alternative for PDF editing and creating forms that I have found is PDF Exchange Editor, which does almost everything Acrobat Professional does at a very low price. Even interactive forms with javascript are possible. Prepress flight checking is not included, though.
It also presents the user with a much more focused GUI than Acrobat (which is a confused over-designed mess in Acrobat).

This has been requested many times before I realize, but I am going to reiterate it one more time.
As it stands, the export persona is pretty much useless, because it doesn't allow for a real-time preview of the rendered asset(s) to check the quality before export. Therefore, I don't use Photo's export option, and instead export a full quality PNG and optimize in external software.
There are a number of other issues with the export (jpeg quality<->file size, inability to set >256 colour PNG output, lack of dithering options and resample options), but this is really the major one. I don't understand why this wasn't implemented in the first place, but hopefully it will be at some point.

Sorry if this is a bit OT, but I think there is a similar problem with the Assets Panel in Publisher. It would be really nice if you could change the size of the thumbnail and if it wasn't cropped to fit a square. 

If that is what they were/are thinking (which I very much doubt), than that is up-side down thinking indeed.
In truth, the entire layer panel in Photo is in dire need of a redesign. Just that checkbox to hide and show layers, and placement of the checkbox to the far right of a layer thumbnail is quite bad GUI/UX design, and just needs to be fixed.
I've discussed this in another thread a while ago, though, and it doesn't really need repeating here. Suffice to say, compared to the layer panel design in Affinity Photo (and Designer), almost any other image editor (commercial and free) provides the user with a (far) better user experience. And it is not only the Layer panel GUI design that is an issue, but also layer management, or lack thereof. Other applications allow for colour tagging of layers, searching for layers (and types of layers), seamless zooming in and out of layer thumbnails, clear indication whether advanced layer blending options were used, and more.
I expect the Affinity developers are aware of the issues related to the current Layer panel implementation compared to the competition, and will improve things by version 2. Rome wasn't built in a day.

If that is what they were/are thinking (which I very much doubt), than that is up-side down thinking indeed.
In truth, the entire layer panel in Photo is in dire need of a redesign. Just that checkbox to hide and show layers, and placement of the checkbox to the far right of a layer thumbnail is quite bad GUI/UX design, and just needs to be fixed.
I've discussed this in another thread a while ago, though, and it doesn't really need repeating here. Suffice to say, compared to the layer panel design in Affinity Photo (and Designer), almost any other image editor (commercial and free) provides the user with a (far) better user experience. And it is not only the Layer panel GUI design that is an issue, but also layer management, or lack thereof. Other applications allow for colour tagging of layers, searching for layers (and types of layers), seamless zooming in and out of layer thumbnails, clear indication whether advanced layer blending options were used, and more.
I expect the Affinity developers are aware of the issues related to the current Layer panel implementation compared to the competition, and will improve things by version 2. Rome wasn't built in a day.

If that is what they were/are thinking (which I very much doubt), than that is up-side down thinking indeed.
In truth, the entire layer panel in Photo is in dire need of a redesign. Just that checkbox to hide and show layers, and placement of the checkbox to the far right of a layer thumbnail is quite bad GUI/UX design, and just needs to be fixed.
I've discussed this in another thread a while ago, though, and it doesn't really need repeating here. Suffice to say, compared to the layer panel design in Affinity Photo (and Designer), almost any other image editor (commercial and free) provides the user with a (far) better user experience. And it is not only the Layer panel GUI design that is an issue, but also layer management, or lack thereof. Other applications allow for colour tagging of layers, searching for layers (and types of layers), seamless zooming in and out of layer thumbnails, clear indication whether advanced layer blending options were used, and more.
I expect the Affinity developers are aware of the issues related to the current Layer panel implementation compared to the competition, and will improve things by version 2. Rome wasn't built in a day.

If that is what they were/are thinking (which I very much doubt), than that is up-side down thinking indeed.
In truth, the entire layer panel in Photo is in dire need of a redesign. Just that checkbox to hide and show layers, and placement of the checkbox to the far right of a layer thumbnail is quite bad GUI/UX design, and just needs to be fixed.
I've discussed this in another thread a while ago, though, and it doesn't really need repeating here. Suffice to say, compared to the layer panel design in Affinity Photo (and Designer), almost any other image editor (commercial and free) provides the user with a (far) better user experience. And it is not only the Layer panel GUI design that is an issue, but also layer management, or lack thereof. Other applications allow for colour tagging of layers, searching for layers (and types of layers), seamless zooming in and out of layer thumbnails, clear indication whether advanced layer blending options were used, and more.
I expect the Affinity developers are aware of the issues related to the current Layer panel implementation compared to the competition, and will improve things by version 2. Rome wasn't built in a day.

If that is what they were/are thinking (which I very much doubt), than that is up-side down thinking indeed.
In truth, the entire layer panel in Photo is in dire need of a redesign. Just that checkbox to hide and show layers, and placement of the checkbox to the far right of a layer thumbnail is quite bad GUI/UX design, and just needs to be fixed.
I've discussed this in another thread a while ago, though, and it doesn't really need repeating here. Suffice to say, compared to the layer panel design in Affinity Photo (and Designer), almost any other image editor (commercial and free) provides the user with a (far) better user experience. And it is not only the Layer panel GUI design that is an issue, but also layer management, or lack thereof. Other applications allow for colour tagging of layers, searching for layers (and types of layers), seamless zooming in and out of layer thumbnails, clear indication whether advanced layer blending options were used, and more.
I expect the Affinity developers are aware of the issues related to the current Layer panel implementation compared to the competition, and will improve things by version 2. Rome wasn't built in a day.

If that is what they were/are thinking (which I very much doubt), than that is up-side down thinking indeed.
In truth, the entire layer panel in Photo is in dire need of a redesign. Just that checkbox to hide and show layers, and placement of the checkbox to the far right of a layer thumbnail is quite bad GUI/UX design, and just needs to be fixed.
I've discussed this in another thread a while ago, though, and it doesn't really need repeating here. Suffice to say, compared to the layer panel design in Affinity Photo (and Designer), almost any other image editor (commercial and free) provides the user with a (far) better user experience. And it is not only the Layer panel GUI design that is an issue, but also layer management, or lack thereof. Other applications allow for colour tagging of layers, searching for layers (and types of layers), seamless zooming in and out of layer thumbnails, clear indication whether advanced layer blending options were used, and more.
I expect the Affinity developers are aware of the issues related to the current Layer panel implementation compared to the competition, and will improve things by version 2. Rome wasn't built in a day.

I don't believe an official feature request place exists, but you could try these:
https://blender.community/c/rightclickselect/
https://lists.blender.org/mailman/listinfo/bf-funboard
https://blenderartists.org/
The last one is visited by developers, but the first one is probably your best bet.
 
PS Spitznamen sind oft ein Wirrwarr in verschiedene Sprachen. Als Kind habe ich immer Raumschiff Enterprise aufs Deutsch ferngesehen. Später musste ich mir dann an die Englische Version gewöhnen. War nicht leicht. Die Deutschen Stimmen von Doris Day und Quincy hören sich noch immer besser an.

Yes, all true, excepting one thing: Next Gen wasn't the first feature length animation done in Blender. The same studio produced Ozzy with Blender in 2016. Even before this time Plumíferos, a feature length Argentinian animation film,  was released in 2010 in Argentina. (And before that the production team of Secret of Kells, released in 2009, used Blender for a number of scenes as well, but only for small parts.)
Anyway, yes, I wholeheartedly agree that Cryptomatte support in Photo would be great, but I am afraid it is too 'niche' for Serif to do so soon, if ever.
PS The Blender devs are finishing up "industry standard" mouse and keyboard controls, so you should be able to seamlessly transition from Max to Blender 2.8 soon. 2.8 is looking great!

For those who want to try this out for themselves, the upcoming Blender 2.8 (beta can be downloaded) includes Cryptomatte as well - for free! And with the built-in compositor it is easy to convert these cryptomattes to masks.
Download the 2.8 beta here: https://www.blender.org/2-8/
 
 

For those who want to try this out for themselves, the upcoming Blender 2.8 (beta can be downloaded) includes Cryptomatte as well - for free! And with the built-in compositor it is easy to convert these cryptomattes to masks.
Download the 2.8 beta here: https://www.blender.org/2-8/
 
 

@Chris B My Publisher is set to Bilinear (best quality) when I tested this.
It is easily reproduceable:
create a 4500x4500 image in an image editor, draw some geometric shapes, some with, and some without aliasing. set the PPI of this document to 900PPI. Save. Import four times in Publisher. Position the first layer at exact pixels (for example, X:100px, Y:100px. Position the second layer at decimal pixels. I did .5 pixel values. Position the third layer at a non-decimal X value, and a decimal .5 value for Y. Leave the fourth version. Rasterize the first three layers. Result: three different rasterized versions. Zoom in to see the difference. Publisher uses the same internal code as Photo and Designer to rasterize layers. Ideally this should not be the case, in my opinion, and the positioning of an object in Publisher should have no impact on what it looks like after rasterizing.

No worries, I misunderstood your original question as well.
As a matter of fact, I never ever scale down my images in Publisher (or any Affinity product or even Photoshop) and always scale down at the exact required size in other tools that do support better down-scaling algorithms (such as Catmull-Rom).
One more thing to consider is the effect of sub-pixel positioning in design software: if the artwork is placed on a sub-pixel position, when rasterizing it may result in a very soft looking conversion. In some software this may play a negative role. I know it does in Affinity Photo, but I am unsure about Publisher. Have not tested it.

Out of curiosity I imported the same 900ppi image three times, and positioned it at sub and exact pixel positions. The result is disheartening: I would expect all three to process exactly the same, because Publisher should in theory NOT worry about the exact positioning of an image. You'd expect this to be a purely internal processing.
As it turns out, this is not the case, and Publisher retains the same behaviour as its siblings: I positioned one 900ppi 4500x4500px bitmap with a rectangle three times on an A4 page in Publisher, and positioned one pixel precise (typing in px in transformation box), one at X:.5, Y:.5, and one at a pixel precise X, y:.5
I would have hoped for the same result in all three cases, but Publisher instead calculates the absolute positioning on the page as a extra factor. It really should not do that in my opinion. It should take the image "as is", and work from there. At least, that is my opinion.

 

It depends on the print job. Not all print jobs rely on only 300ppi images: for example, I print comics, and the line art is imported as a monochrome bitmap (tiff) at 1200ppi, and then overprinted on top of 300ppi colour work.
You'd expect the black and white art to be printed at an image setters native resolution (double that 1200ppi, just about), but paper of course sucks up that ink, and it will not hold that sharpness. So with this type of printing comic publishers tend to stick to 800~1200ppi for line work.