Pšenda

... and sometimes concepts from two different OSes are mixed, so that Windows users are forced to use some kind of control from Mac (for example, moving Studio control from the View menu to the Window menu, which is said to be a Mac custom, even though in Win this menu is intended for managing open documents), or vice versa.

Ah, this is annoying indeed. Whereas there appears to be a general lack in the UX concept in Affinity, not especially in the opacity 'feature' only.
Oddly the different panels have different UX applied too their fields: Some get activated by a click on the field label while others don't, and some fields remain selected after the pressed enter key while others don't.
Additionally confusing is that the different behaviours seems to be not related to the obvious UI of the panels/fields. For instance the various fields can have …
… two up/down arrows or
… a pull-down menu or
… a pop-up slider or
… a permanent slider
aside the field to increase/decrease its value with the cursor, via drag or click-select.

Why? - because after several decades of using applications (at least on Windows) I'm used to the fact that when I select some edit field (for example, the X/Y positions in the Transform panel), then after pressing Enter (which causes the entered value to be accepted and applied), this remains field still selected/focused. So if I find that the newly entered value needs to be corrected, I start typing on the numeric keypad again. Which unfortunately doesn't work in Affinity apps, and I have to like an idiot keep selecting the X/Y box over and over again until I finally get the exact location, and then of course I change the Opacity every now and then.

Personally, I would like the following color highlighting of groups and their items (idea vs reality).
 

Drawing a hierarchy with vertical lines is a common practice, for example in source code editors, but to improve orientation, the lines are color-coded.

Something similar would be useful for displaying the hierarchy in the Layers Panel, but it will clash with the current trend of "fading" and "decontrasting" Affinity applications. The current solution is really unclear with a greater depth of hierarchy.

Alternatively, their color differentiation/highlighting would be useful.
 

Maaaan you saved me
i really was missing this feature. Thank you so much.

Select node with Node Tool, set Transform Mode, resize (with Ctrl + Shift).

I agree. This was true for the V1 version (see also dozens of posts on this topic), and in V2 version it just got worse.
An incomprehensible step for me.

I think that for a company that has to sell its sw, it is not important how many people "speak" what language, but how many people will buy their product.

Hi,
when setting the insertion target mode to e.g. "inside", this will apply to only one layer adding, and then reset to "on top" automatically. This makes no sense.
 
https://affinity.help/photo2/English.lproj/pages/LayerOperations/target.html

The new system is far more suitable for many users/situations and formally more correct, because it is simply not correct to define two completely identical documents with completely identical parameters just for the sake of orientation. So it is not a bad decision (on the contrary) that does not need to be revoked, just it is only sufficient to supplement it with the possibility of keeping orientation as it was proposed a long time ago. 
On 12/12/2022 at 11:55 AM, Pšenda said:
Therefore, it would be appropriate for the user to be able to select/choose if the preset is created without an orientation definition, or if it is specific to only one type of orientation.

From the point of view of the developer of some software, the main point of view is its "marketability" - i.e. the number of buyers, not some number of readers or printers. A high number of readers/printers creates certain assumptions of a high number of potential buyers, but it certainly does not have to be a direct context. Apparently, Serif made an analysis that the cost of development for complete RTL support (and that includes the suspension of work on further improvement of the applications) may not be sufficiently compensated by higher sales.

I agree that this is intended behavior - orientation is not part of the Preset. The Preset defines only the parameters of the document - its dimensions, margins, color format and profile, but not its orientation.
By the way, it would be quite impractical to have two different presets for a completely identical document, just because both orientations would have to be defined.

And why should preview slow down your work? - just ignore it, don't wait for the preview to finish and do export.

Ad 1) Why don't you use Force Pixel Alignment (with unselect Move By Whole Pixels)? 

Other users may find it useful though.
Rather than killing it I would advise you to post your suggested improvements to the beta forum so the team can evaluate your suggestions.
That way you get improved export preview and we all will benefit from your suggestions.

If you haven't noticed yet, Serif by principle doesn't comment on feature requests, and certainly doesn't promise any deadlines.
If this should be implemented in version 2.1, I recommend watching the Beta forum.

Click to application icon, click to Size, and arrow keys pressing?

In order for our QA team to replicate this, we set the display resolution to 1920 x 1080 (or used a 1080p monitor) and used 100% Display Scaling in Windows.
Then, by manually editing the Affinity setting file that controls the window size (window.xml) to a very specific resolution, 1936 x 1056 and then attempting to drag the window, causes this to occur.
I highly doubt that these are steps you have taken for this to occur, so I'm unsure of why this has been observed on multiple machines for yourself at this time, my apologies.
I wasn't aware of this Windows feature, thanks for teaching me something new
I can also see when using this Size option and holding down the left/right arrow keys it causes the application to 'jump' rather frantically on my PC, so I'll be logging this as a separate issue with our team now.

@Pšenda
Thank you for your response.
That worked!!!!
If anyone wants to try that. I had to 'shrink' the program first, so it wasn't full screen and move the program to the right a bit, then click on the icon to resize. But once I did the sides of the program showed up! Once the sides of the program were visible, I was able to resize the screen and it seems to be holding. 
Thank you sooo much. 

I don't recall seeing another report in the forums in the 5+ years I've been reading them. 
My guess is it's something you've done or installed. Perhaps you have one of the third-party apps installed that cause problems? 
 
 

Try search about Snapping Candidates, or Purple line.
https://www.google.com/search?q=purple+line+site:forum.affinity.serif.com
 
 

I'll just add that Esc also works.
But the absolute standard is for the less "harmful" option to be preselected (focused), and just press Enter.

Which of the options is less harmful is a matter of opinion - I favor the Save option. The point is that the user requested to close the modified file. So the harmful thing is that the close is completed without saving, so the user loses his work. If Cancel is executed, the edits are not lost (but it wasn't even saved, so the risk of data loss still remains), and the user's primary command to close the file is not executed. In the case of Save, the file is saved so that the edits are not lost, and the primary command to close the file is executed - in my opinion, the least harmful/intrusive operation.