lacerto

Even for "somewhat" it is too far from the requested solution which at least would result in an identical appearance for same glyphs, independent from their x/y position. Compare the OP's initial screenshot of the wanted goal with the different rendering of your workaround: every of the 6 characters has another look. (the bottom row has a different curve map set)

Or perhaps we're only holding it wrong…? 

To avoid the negative term altogether, one could also say that it is implemented in "Affinity way" 🙂, which, if you want to be nice, is just "different". 

To avoid the negative term altogether, one could also say that it is implemented in "Affinity way" 🙂, which, if you want to be nice, is just "different". 

Sorry, the previous testing of GIMP was not rigorous enough. I tested it again and after removing the anti aliasing, the results were consistent with PS. This also excited me. I have a new solution to replace PS. It's great, buddy.

Disregarding the font, it seems that there are app-related differences that are fundamental as for rendering of non-antialiased type. I initially (and naively) thought that turning off antialiasing in Blend Options would "simply" just revert to turning off resolution-dependent skeleton glyphs math. That is, that having "None" as an antialiasing method in apps like GIMP, Photoshop and any of the Affinity app trio would give identical rendering, when having the same document DPI.
That it is obviously NOT so, it is a worth of a more fundamental study or declaration!

Had thoughts/explanations in response to your post yesterday, and the new post today - but just don't feel like contributing to the Affinity forum today...for some reason...

Yes, this happens because Affinity apps do not support global layers. They are page specific, also when exporting PDF (OCG) layers.

Well holy sh#t, I was about to post the old "what chu talkin bout Willis" line, but thought I'd do a quick Google first, and wow 😲

This is HUGE news, and I'm a little miffed we didn't hear it first from the company we have supported and trusted for many years. I personally hate what Canva has done to the design industry, however I can only assume they have the $$ and resources to actually give Adobe a run for their money, on top of that we may finally get image tracing!! Speaking of money, we should prepare for the inevitable subscription-based model, and / or price increase to return the unconfirmed billion-dollar acquisition to investors pockets.

Overall, I'm quite torn about this news, yet not surprised.

The honeymoon is over.

Some of the "features" are actually OpenType (OT) features and some are constructions by the application. For example there is no All Caps feature in OT.
Character Variants (cvNN) is an actual OT feature which Affinity does support when it is actually present. To test take a look at the fonts Charis SIL and Junicode. They both have OT Character Variants. ID does not support cvNN at all (there is an add-on available which does).
Affinity only shows the actual OT feature Access All Alternates (aalt) if it actually exists in the font. Adopey apps construct this (whether it actually exists or not in OT) and that is what is displayed in the alternates pop-up. 
Groovy Script actually has an aalt feature and the font developer actually created it manually (more advanced font editors can create it automatically). Pluses and minuses - Automatically may create duplicates and odd exceptions - Manually may miss alternates but could also be a well thought-out and better.
It appears there is a newer version of the font with more features than the version I have (v1.000).
Regarding the Stylistic Sets (ssNN) - it appears the newer font may have multiple alternates on the ssNN (like on cvNN). Junicode 2 has started doing this. Because they have more than ss01-ss20 (and do not want to exceed ss20). Some apps will work all the way up to ss99 (APub, ID, LibreOffice), and some fonts will use up to ss99. And some apps will only display up to ss20 (Word). And some do not work with the ssNN variants. Since ID does not support OT Character Variants at all, I assume it also may not support variants in Stylistic Sets.
And on and on...
Would have to see the newer font to determine exactly what is happening.
 
Additional thoughts...
- applying some OT features will block other OT features (depends on the order inside the font)
- fonts may have errors/bugs in the OT features. The more complex the font, the more likely there are issues. 

Yes, I agree. But I am not sure about the parallel case with a JPG file (when saving back keeps the CMYK format because it is technically possible). If saving back without confirming an overwrite is supported in the first place, what kinds of operations would be radical enough to require a user confirmation -- switching the color mode IS a big change so at least it is a good candidate; but there are limitless ways to completely change an existing image and it would be difficult to decide a reasonable trigger for a warning.

You cannot technically save an opened .PNG image as a CMYK file (even if Affinity app will seemingly allow saving a CMYK .PNG file "back" with existing file name). When you close and reopen the file, it will still be in RGB color mode (but at least the colors are not messed up, as they used to be at some point). [So, after conversion, export the image to a file format that supports CMYK, like JPG or TIFF.]

You cannot technically save an opened .PNG image as a CMYK file (even if Affinity app will seemingly allow saving a CMYK .PNG file "back" with existing file name). When you close and reopen the file, it will still be in RGB color mode (but at least the colors are not messed up, as they used to be at some point). [So, after conversion, export the image to a file format that supports CMYK, like JPG or TIFF.]

It seems that blend mode fill opacity does not actually work at all for certain blend modes (e.g. Vivid) and color values, e.g. in the clip below where a blue ellipse on top is blended with an underlying rectangle with linear gradient from R255 G0 B255 to white (so the objects are sharing the blue channel all the way). There is no gradual change at all, but decreasing the fill opacity from 100 towards zero has the same "blend effect" right from 99% to 0%. In different conditions blend mode fill behaves less radically different compared with identical objects with reduced color and layer opacity but as for the assumed gradualness of fill opacity, the functionality simply just seems to be lost (= opacity is just 100% on or 100% off).

fillopacity_blendmode.mp4    

Erase blend mode easily back fires when combined with adjustments (like inverting curves), and it basically always needs something against which to erase so if your purpose is to create cuts (see throughs) and place them on top of arbitrary backgrounds in other documents, this does not work. As mentioned, you need to create such shapes by using vectors. But if your design is self-contained and rasterization is not a problem, then Erase mode can be a great way to create the kinds of distressed textures your are having here.

Like so many perculiarities,oddities and non sense making defaults in the affinities, this has been reported many times and even have been provided with solutions to use other modifier keys.
But remains just another  "by design" faillure.

If you want to scroll vertically, buy a mouse with a scroll wheel. There's nothing wrong with using a trackpad, but a trackpad on a movable mouse leads to inadvertent horizontal scrolling.
I don't have a Magic Mouse to test this on, but you could try turning off horizontal mouse scrolling in macOS.
https://discussions.apple.com/thread/254473197?sortBy=best
 

You're right. I probably should clean my glasses more often. I'll delete that.

It is quite confusing. Check the video clip below to better understand how color controls in Affinity apps operate and how you can determine the actual color that an object has been assigned with:

whatcolordoihave.mp4 In a nutshell: the two ways to find out the actual color a text or native object (shape) has, is to use the Color panel and turn the lock off (on macOS, you might need to de and reselect an object to have the color values of a model made active updated), or using the color creation button when creating a swatch in a document palette within the Swatches panel (and having the list view turned on so that you can directly see to color component values). Note: Remember to switch back the lock in the Color panel to avoid inadvertent color mode conversions since if the lock is turned off, just switching the color model in the Color panel will result in conversion of color mode of a selected object. [EDIT: Note especially that using color pickers will NOT show the true underlying color model of an object that you use the color picker for, but the color value of that object when converted to the active color mode that the document is currently using (and that can be switched, without causing conversion of existing color values of text and shapes; values of pixel objects, however, would be auto-converted when switching the document color mode).]
As for other controls, e.g. the Font Color rectangle on the context toolbar, or the Text Fill rectangle in the Edit Text Style dialog box, simply just switching the color model does NOT automatically convert the color model of underlying style, or selected object. But Publisher will "remember" the last model that was selected in these contexts so if you change to "CMYK" model, the next time you access the same controls, they would show CMYK models. Note that actually typing in color values or selecting a color when using a specific color model, would result in redefining a color value for a selected object, so always be careful when using color controls in Affinity apps. [EDIT: As for styles, you can also find the actual color definition in plain text, if you drill down deep enough and read the style definitions of the base style.]
Note too, that the active document color mode in Publisher (or other Affinity apps) does not mean that colors that you define for objects (texts and shapes) would be automatically converted to the document color mode (which many other apps do); instead, they will be saved in meta data of each and every object you create or edit, so different objects within a document can well have definitions based on different color models, like RGB, HSL, Grayscale, CMYK, and Lab. 
So, to recap: In most contexts, just switching the color model within a color selector, will NOT result in conversion of the underlying color definition for a selected object, but only actual color selection, or typing in a color value (even if the same as the object currently has), will. But in the Color panel, just switching the color model WILL, unless the small lock icon is turned on (and by default, when you create a new document, it will be turned on). 
 
 

Agreed.
 
I have attached a set of macros below created with Affinity Photo 1.6.5.135, including one for 120DPI.
Importing:
1) Ensure the Library panel is active in Affinity Photo by going to [Window > Library].
2) In the Library panel, click the "hamburger" menu in the top-right corner.
3) Select "Import Macros…".
4) Import the below Affinity Photo Macro file.
Macro Set:
DPI (Affinity 1.6.5.135).afmacros
Screenshot:

 

@Callum, the workflow with an upsized layer copy works fine for rectangular images and certain shapes only. It appears to fail if the shape changes its angle or with details in an aspect ration other than square/circle … see what happened to the feet/toes …


… or the stem of this pear:

(the required solution would rather work like AD's Contour Tool with vector + combined with APh's Inpainting Brush or Fill.)

Thanks, that is useful!
I have a yearly need for updating 4-bit dithered RLE compressed bitmaps using a custom palette, and Photoshop CS6 has a bug when saving back to 4-bit. Current version of PS has this bug fixed but I will stop subscribing sooner or later, and Magick could be a good replacement.
Btw: I could not make +dither work for turning off dithering but 'magick clipboard: -define dither:diffusion-amount=0% -colors 16 bmp3:im_nodithering.bmp' can be used as a workaround. 
UPDATE: Having played with ImageMagick for a few hours, my conclusion is to recommend GIMP as an alternative, if Photoshop is not available. It handles e.g. Floyd-Steinberg dithering especially with colormaps way better (much in Photoshop style) than ImageMagick, and if retaining of existing palette is important, GIMP is probably the best free tool available for the job. [But because command line tools typically have a pretty steep learning curve, it may well be that I have just failed to learn use the tool optimally.]

magick identify -verbose test.bmp
reports 3 colors so I used 4 but yeah 16 won't do any harm
it also shows uncompressed so I left that alone. If you add say
-compress RLE
then the file size reduces dramatically but maybe the OP's program won't handle it, Photo can't although Photoshop, Photos, Irfanview and Chrome can
test16RLE.bmp

It seems this is pretty complex. First of all, when exporting from an RGB document to an RGB PDF, the only gradient that made it through to Adobe Illustrator as a gradient, was one on the bottom left which has three stop points defined. The one on the top left (with only two stop points) made it through non-rasterized as "non-native art". Both rectangles on the right were rasterized, no matter what. They were possibly defined a bit oddly (with transparent tool instead of defining opacity directly for stop points?), and mixed with HSL and RGB definitions, but changing this (removing transparency tool settings and defining all stops in RGB with opacity values) did not seem to have any change in behavior when opening exported RGB PDFs in Illustrator (CS6 was tested).
But I had earlier tested this only with CMYK exports, and it seems that is crucial; note that you need to export using settings that retain live transparency (any non-PDF/X-based preset, or PDF/X-4).
When you do, the gradient itself is retained, and transparency is achieved by using an opacity mask with gray levels indicating the level of transparency:

Attached is a Designer document where I have taken the bottom left rectangle with three stop points and added reduced opacity levels for two stops and then exported using PDF v1.7 to CMYK. As can be seen, when opened in Illustrator, the gradient is retained (showing as "Path"), and above the opacity is being edited by activating the opacity mask and setting the gray value of the middle stop (I made it 42, the same as location value, which is same as 58% gray). A green rectangle has been placed below to demonstrate the gradually increasing transparency.
This seems to be a PDF limitation within Affinity apps, since when exported to SVG (always RGB), there are no problems retaining the gradient when opened in Illustrator, and opacity values are directly defined for stops:

The Designer document used for exporting the gradient is attached, as are the exported PDF and SVG.
 gradient_with_transparency_exportable.afdesign
gradients_exported_cmyk.pdf
gradient_with_transparency_exportable.svg

Interestingly, forcing conversion of image color spaces in context of PDF/X-based export methods also seems to restitute the "K-Only" effect for "K-Only" images that have adjustments applied (and which otherwise result in conversion to four-color state when exported). When examined in Adobe Acrobat, such objects seem to have both grayscale and K-ink version of a CMYK image included in PDF/X-4 and all non-PDF/X based export methods, but the values show as K-values only in PDF/X based versions. PDF/X-1 and X-3 only have the CMYK K-ink included. This is quite confusing (and also feeble, knowing the restrictions involved in PDF/X-based export methods).