R C-R

Does turning off "Wet Edges" in the Context Toolbar get you what you want?

In your screenshot, did you overlook the red text telling you that you need to update both Affinity Designer & Affinity Photo for StudioLink to work?

DPI is irrelevant unless the file is printed, at which time it can be set to anything, since it is just metadata that the printer may or may not use. EDIT: please refer to https://affinityspotlight.com/article/understanding-dpi/ for more about this.

In point of fact, quite often it is suggested to try a different graphics driver or to check for conflicting 3rd party stuff known to cause issues with the app. If that leads to a solution that allows the use of hardware acceleration then the issue typically is considered resolved by the user. How specifically could this self-test routine change the settings to avoid a crash that stops the test? Once it crashes, that's it. There is nothing left to say why it did or if it is fixable.

If nothing else, imagine how users would react if the crash was caused by an incompatible add-on & they later learned that by simply either removing it or making an exception for AP if it provides for that, then they could use hardware acceleration. Same for a damaged or missing file (in either the app or the OS) that could be replaced with a good copy.

No, it just means that something in a thread running in the benchmark test that was using hardware acceleration caused a thread crash, but that by itself does not mean hardware acceleration is unusable. This is because there could be other causes that if identified & eliminated could make it usable. I mentioned several examples of fixable causes above.

What info specifically could any app recover from a thread that has crashed, other than that it has terminated for some reason? After all, there could be several different causes for that, including conflicts with third party 'helper' add-ons, hardware level component defects, or damaged/corrupted files or the file system itself. Few of these things should prevent the user from enabling hardware acceleration, if nothing else for diagnostic reasons.

As for the "touching the text" part, for Frame Text the Paragraph panel has various controls that allow you to set the alignment, justification, & spacing on a paragraph by paragraph basis.

Actually, a lot of the topics are about Affinity itself crashing, not just one of its threads. But even if it is just one or a few threads that crash all the app can do is terminate those threads, so if that thread is one of those the benchmark must run during the test, there is no way the app can get any performance info from that test other than it did not complete after some pre-defined period of time. Same problem if the app hangs & has to be force-quit. What it might be able to do is write a temp file somewhere before starting the test with info about its start time & what configuration it is testing & delete it if the test completes, so if the app has to be restarted by the user it could check for that, but I do not see any way the app could automatically restart itself.

I don't see how AP itself could 'handle' anything if it crashed or hung while running the benchmark. It seems to me this is something only the OS could detect.

They do, but over the years there have been so many different feature requests (including disagreements about how they should be implemented) that they have been forced to pick & choose sparingly among the ones they think will benefit the greatest number of users to focus their development efforts on. There are hopes that now that deep-pockets Canva has acquired the company that things will improve in this respect but nobody can say with any certainty if that is realistic or not.

How could it do that if the app crashed while running the benchmark or if the driver never returned control to the app? Doesn't the app have to complete the benchmark test to gather any info about the results?

The problem with that for Windows is there are hundreds if not thousands of possible combinations of hardware & driver software versions in use by users.

When I use New from clipboard, I always get the same size in pixels of the copied object in both (actually all 3) apps. So could it be that what you see is because you are using different units of measurement or resolutions in the apps? If not, could you post a small *.afpub document with just a few objects in it, tell us which one(s) you are copying to the clipboard, & also the *.afdesign document that you get when you use New from clipboard in that app?

How much clearer than what @Patrick Connor already told you above does have to be before you understand that the policy has not changed?