lacerto

I never liked XP1/2, much preferred FP3/4, HPS, Tri X generally developed in ID11. I dumped all of my darkroom stuff except the enlarger which is a pre-war Focomat and a thing of beauty
Anyway, back to the scan, as a confirmed Luddite I check the channels on scans and choose the one with best contrast, in this case the red
Then create a greyscale layer and apply a curve adjustment

It is possible, since I initially created this file in Illustrator and used a different blend mode in each rectangle, and additionally applied 50% opacity for all objects. There were no groups initially, but I saved this file as SVG 1.1 from AI CS6 just to see that Illustrator at this point did not export blend modes in any of the attribute encoding styles (I am not sure if CSS Level 3 and blend modes were even developed at that time (around 2011). Anyway, I think that I opened one of these SVG exports in Designer and then exported directly to SVG again to see the differences. I thought that I had checked from the code that there were no blend modes but just opacities. I, too, tried to manually reproduce the strange random rasterization using similar group and passthrough inherited opacity values, but could not, so perhaps this is somehow more or less a unique case. 

You're welcome. I later printed this from Adobe Acrobat Pro onto my local printer on an A4 sheet, and the distances remained at 5mm throughout (180mm total from first to last point) so there is nothing wrong with the PDF. I would check two things: that you do not accidentally have scaling down to paper size other than Letter on the second tab of your Brother driver, and that if you have multiple trays, there is no setting that forces feed from a wrong tray (automatic selection might also fail sometimes so forcing paper feed manually from the right tray might be worth a try).
It might also be useful to check that you do not have wrong default paper size set in the printer's own control panel (which you should be able to access also via browser). I have noticed that sometimes paper size selections made via driver or manufacturer's own printer app do not "take" (I am not sure if this is something that is related to ongoing changes in Windows 11 OS -- I have recently had all kinds of minor issues with my newish Xerox color laser printer which make me wonder if this company really has what it takes to get ink (toner) on paper, somehow I have assumed so...). Anyway, these kinds of errors can often be fixed by restarting the computer, or unlnstalling and reinstalling the printer driver and the app (I have done this a few times already).

Thanks for the update. This was an instructive thread, because the job at hand appeared to be very simple, and what was confusing, was basically the very different way Adobe InDesign and Affinity apps handle "grayscale" (or basically, press-oriented black). InDesign does not basically offer "grayscale" color model at all, but uses instead Lab for specifically light intensity oriented color definitions, and for print intent documents always handles "gray" as K ink. So it is very straight forward. Whatever is defined in print intent document and using the factory default {Black] swatch (including tints) will end up on K plate when exporting to press, and stay "grayscale" in that sense. Similarly, imported grayscale images will aways stay on K plate, there is no need to explicitly tell that gray is not a composite RGB but needs to be treated as black ink.
What however was particularly confusing was bringing in PDF/X-1a and combining it with concept of grayscale, and specifically in context of InDesign, since when using this standard, conversion to grayscale proper is not available at all in InDesign (at least up to CS6), so to be able to produce specifically grayscale PDFs, anything else than PDF/X-1a needs to be chosen! PDF/X-1a is often asked for the purpose of guaranteeing that the job will be in CMYK-only color space and will not contain live transparencies, and is therefore a kind of fool-proof export method. 
So, to wrap up, what seemed to have happened was that as you had a pure b/w press-oriented job, you initially chose the Gray/8 document color mode and assumed that text and native art is safest to specify in  CMYK, using K ink only (as you would do in InDesign or Quark, where gray is not even available). Which in Affinity apps is wrong, since K would be handled as an RGB value in a grayscale document and would end up being either a four-color black or a diluted black (dark gray) depending on whether exporting to Grayscale or CMYK. So: in a Gray/8 color mode document, you need to define blacks (text and native art) that are intended to end up on K plate, as Grayscale or RGB color values, and make sure that you also export using Grayscale color mode (using CMYK at export time would convert grays to four-color black).  Placed grayscale images would also be converted to rich black. Using PDF/X-1a in context of a grayscale document, would work if you had press-oriented grayscale profile available (which Generic Gray Profile or D50 are not), so in this sense the color preflight warning that you would get trying to export using PDF/X-1a in context of a grayscale document, is correct. You will end up having four-color blacks if you use PDF/X-1-a:2003.
The next step you tried was probably switching the document color mode to CMYK/8. You already had your text and possible native art defined in K100 so it would seem obvious that you will have correct output having K-only color definitions and placed 8-bit TIFF grayscales. But no, your placed TIFFs would now be exported using four-color-black, as they would be treated as RGB images within Affinity apps whenever placed in Gray/8 or RGB color mode document, but handled in CMYK context, and would be exported as rich black when exporting to CMYK. Using PDF/X-1a would not change anything here.
At this stage, at latest, you might have heard an instruction from the printer to produce in true "grayscale", in the meaning: everything on one/black plate. The trick, in Affinity apps, is to apply the "K-Only" button on all placed grayscale images. This would not be done when placing these images in other than CMYK document color mode, and it won't be done automatically if switching the document color mode to CMYK. The button is also visible on the context toolbar only when using CMYK document color mode, and unfortunately you cannot apply "K-Only" for all document images at once, but need to go through images one by one and make the change. Note that when you have a document color mode in CMYK, placed grayscale images do have K-Only button automatically applied (and the mode will be retained also if you subsequently switch document color mode even if the button itself is hidden, which would also change the way these images are treated in these alternative document color modes when exporting to different color spaces).
After this, you would finally get what you need: "a simple grayscale" job where what you have defined in K-ink only and with imported TIFF grayscales, will be delivered as expected on one (K-plate) only (whether exported using PDF/X-1a or not). You should additionally be careful not to change color profile at export time, since that would, again, convert K-only colors to four-color values. [ALSO: It is good to remember that letting Affinity apps embed ICC profile in the document (= default), will produce an ICC-dependent PDF where using wrong simulation profile will show incorrect CMYK values in Adobe Acrobat Pro so there is still this additional confusion related to complexity of defining black ink values within Affinity apps.]
Part of this is related to clash of different technologies and underlying color engines, and terminology (some say "cultures", but I personally disagree), and the fact that you are not likely to get proper instructions from printers / print shops. The Affinity apps are also under development, and there seem to be recent changes e.g. in the way placed CMYK images are treated when they contain embedded profiles (nowadays they are discarded similarly as by default in InDesign). How could anyone expect to get step-by-step instructions from a third-party when they are not provided even by the first-party, practically ever? 

Thanks for the update. This was an instructive thread, because the job at hand appeared to be very simple, and what was confusing, was basically the very different way Adobe InDesign and Affinity apps handle "grayscale" (or basically, press-oriented black). InDesign does not basically offer "grayscale" color model at all, but uses instead Lab for specifically light intensity oriented color definitions, and for print intent documents always handles "gray" as K ink. So it is very straight forward. Whatever is defined in print intent document and using the factory default {Black] swatch (including tints) will end up on K plate when exporting to press, and stay "grayscale" in that sense. Similarly, imported grayscale images will aways stay on K plate, there is no need to explicitly tell that gray is not a composite RGB but needs to be treated as black ink.
What however was particularly confusing was bringing in PDF/X-1a and combining it with concept of grayscale, and specifically in context of InDesign, since when using this standard, conversion to grayscale proper is not available at all in InDesign (at least up to CS6), so to be able to produce specifically grayscale PDFs, anything else than PDF/X-1a needs to be chosen! PDF/X-1a is often asked for the purpose of guaranteeing that the job will be in CMYK-only color space and will not contain live transparencies, and is therefore a kind of fool-proof export method. 
So, to wrap up, what seemed to have happened was that as you had a pure b/w press-oriented job, you initially chose the Gray/8 document color mode and assumed that text and native art is safest to specify in  CMYK, using K ink only (as you would do in InDesign or Quark, where gray is not even available). Which in Affinity apps is wrong, since K would be handled as an RGB value in a grayscale document and would end up being either a four-color black or a diluted black (dark gray) depending on whether exporting to Grayscale or CMYK. So: in a Gray/8 color mode document, you need to define blacks (text and native art) that are intended to end up on K plate, as Grayscale or RGB color values, and make sure that you also export using Grayscale color mode (using CMYK at export time would convert grays to four-color black).  Placed grayscale images would also be converted to rich black. Using PDF/X-1a in context of a grayscale document, would work if you had press-oriented grayscale profile available (which Generic Gray Profile or D50 are not), so in this sense the color preflight warning that you would get trying to export using PDF/X-1a in context of a grayscale document, is correct. You will end up having four-color blacks if you use PDF/X-1-a:2003.
The next step you tried was probably switching the document color mode to CMYK/8. You already had your text and possible native art defined in K100 so it would seem obvious that you will have correct output having K-only color definitions and placed 8-bit TIFF grayscales. But no, your placed TIFFs would now be exported using four-color-black, as they would be treated as RGB images within Affinity apps whenever placed in Gray/8 or RGB color mode document, but handled in CMYK context, and would be exported as rich black when exporting to CMYK. Using PDF/X-1a would not change anything here.
At this stage, at latest, you might have heard an instruction from the printer to produce in true "grayscale", in the meaning: everything on one/black plate. The trick, in Affinity apps, is to apply the "K-Only" button on all placed grayscale images. This would not be done when placing these images in other than CMYK document color mode, and it won't be done automatically if switching the document color mode to CMYK. The button is also visible on the context toolbar only when using CMYK document color mode, and unfortunately you cannot apply "K-Only" for all document images at once, but need to go through images one by one and make the change. Note that when you have a document color mode in CMYK, placed grayscale images do have K-Only button automatically applied (and the mode will be retained also if you subsequently switch document color mode even if the button itself is hidden, which would also change the way these images are treated in these alternative document color modes when exporting to different color spaces).
After this, you would finally get what you need: "a simple grayscale" job where what you have defined in K-ink only and with imported TIFF grayscales, will be delivered as expected on one (K-plate) only (whether exported using PDF/X-1a or not). You should additionally be careful not to change color profile at export time, since that would, again, convert K-only colors to four-color values. [ALSO: It is good to remember that letting Affinity apps embed ICC profile in the document (= default), will produce an ICC-dependent PDF where using wrong simulation profile will show incorrect CMYK values in Adobe Acrobat Pro so there is still this additional confusion related to complexity of defining black ink values within Affinity apps.]
Part of this is related to clash of different technologies and underlying color engines, and terminology (some say "cultures", but I personally disagree), and the fact that you are not likely to get proper instructions from printers / print shops. The Affinity apps are also under development, and there seem to be recent changes e.g. in the way placed CMYK images are treated when they contain embedded profiles (nowadays they are discarded similarly as by default in InDesign). How could anyone expect to get step-by-step instructions from a third-party when they are not provided even by the first-party, practically ever? 

I am not sure what you ask... This scenario was already explained and demonstrated above: having a Gray/8 document color mode, defining colors in grayscale or RGB (virtually same) and exporting using PDF/X-1a method to produce DeviceGray output (no ICC-dependencies, but just output intent description, so nothing to be resolved), the crucial thing being ability to choose a press-specific grayscale profile (which has to be fetched and installed separately).
Obviously OP did not have such a profile installed so they were not able to produce such a file, so in lack of an appropriate profile, the ICC profile field is left blank, and Affinity app will use the app default US Web Coated v2 as the target profile, resulting in all black definition becoming converted to four-color black. So OP ends up using a workaround, producing PDFX-1a in CMYK document color mode with K-only definitions, producing DeviceCMYK file on mere K plate, and converting the file afterwards to Grayscale 1-ink file.
As mentioned, the printer's requirement appears to be unreasonable, but it is possible that they have been offered grayscale exports with 4-color black, and PDF/X-1a CMYK exports with 4-color black, either as a result of profile conflict (document vs. export time), or because of PDF compatibility violation (and resulting rasterization), etc. Or, because of having been offered an ICC-dependent file (even if otherwise meeting the specs). Some printshops have automated preflight checks that may discard a job for practically irrelevant reasons. So the advise given for "Grayscale" might have been a reference to need of having one ink (grayscale job), whether DeviceGray or DeviceCMYK with K plate only, and with no ICC-dependencies. PDX-1a is probably referred as for requirement of needing to have transparencies flattened. 
As explained in many posts on this forum, this primordial requirement is probably made in sincere belief that it is easy to achieve, and that it is a fool-proof method of guaranteeing expected results on paper (as basically what the client sees is what they get, since nothing will be left to be resolved at RIP-time). But within Affinity ecosystem, depending on complexity of publication, producing PDFs meeting these kinds of primitive specs, can become a challenging job that takes lots of knowledge and experience, or long trial-and-error workflow -- especially if a proper preflight tool is not available.
 

Transparent Vectors are rasterised on export to SVG unless Selection Only is chosen in the SVG Export options...
With a Layer (Capital L) or Group selected, exporting to SVG results in the following output when Area is set to:
Whole Document - Some areas will be rasterised
Selection Area - Some areas will be rasterised
Selection Only - Some areas will be rasterised
With the layers (Small L) selected, exporting to SVG results in the following output when Area is set to:
Whole Document - Some areas will be rasterised
Selection Area - Some areas will be rasterised
Selection Only - Nothing will be rasterised

Blurry SVG.mp4 Sample File - courtesy of @lacerto
transparency.afdesign

Have you tested, or is this just based on assumptions? I ask because Adobe still sells Adobe Acrobat Pro 2020 stating that it is compatible with macOS post-Mojave, including Sonoma.
https://helpx.adobe.com/acrobat/system-requirements-acrobat-2020.html

This is so clearly stated in system requirements for macOS that I suppose it is true (but I can understand if they do not advertise this). This of course means that the macOS version must at least have some kind of a 64-bit front end that is capable of running a 32-bit Intel module, since I do not believe that they have created a 64-bit Intel build just for macOS (but this is of course possible, considering that 64-bit Safari browser plug-in is mentioned) -- which would kind of suck considering Windows users; needing to run a 32-bit module is sometimes an annoyance when opening large files that break the 2GB RAM barrier. 
But this forum is probably not the best place to find out how Adobe Acrobat Pro 2020 runs on modern macs and M3 processors on latest Sonoma 🙂 

Note that you could export PDF/X-3 or PDF/X-4 based Grayscale PDF also from Affinity apps, but you need to have a true grayscale print profile installed on the system (I am not sure but on macOS you might have Generic Gray inherently available [UPDATE: Checked, and Generic Gray Profile is inherent on macOS, but is not available whenever using PDF/X-based method]; on Windows [UPDATE: and on macOS, too] you would need to fetch one from the Internet, or have one that comes with QuarkXP or Adobe available), since the only grayscale profile that comes with Affinity apps (Greyscale D50) is basically a display (Gamma) color profile and not selectable when you have a CMYK or Gray/8 document color mode and convert to Grayscale, and use PDF/X-based export method:
 
If you leave the profile empty (or do not have anything available), all the blacks defined above would be converted to four-color black and have Affinity app default U.S. Web Coated v2 marked as the output intent profile. If you do define a true grayscale color profile as output intent, RGB 0,0,0 and B:0 (Grayscale 0) will be output in ICC-dependent 100% Gray (CalGray/ICCBasedGray), but K100 will have something like a 92% value.
See below a PDF/X-3 with no explicit press-specific grayscale output intent (U.S. Web Coated v2 auto-assigned):
pdfx3_gray_from_cmyk_noexplicit_output_intent.pdf
...and a version where a true grayscale output intent is defined:
pdfx3_gray_from_cmyk_quark_genericgray_output_intent.pdf
UPDATE: The same applies to PDF/X-4 production (and in PDF/X-1a only CMYK color mode is available).
If you do not have to use PDF/X-based export method, but force the Grey color space, the default Greyscale D50 would be available, but then, too, K100 values would have non-100% gray values. So whenever forcing grayscale output, you need to have native color values (text and shapes) defined either in RGB or Grayscale, not CMYK.
There might be point in checking whether the printer truly needs PDF/X-based output in grayscale, or whether they just meant K-only output (but accept any regular non-PDF/X based CMYK-based output, as long as CMY plates are empty).
UPDATE: And if they just meant K-only, then the correct method to produce such PDFs is to choose CMYK document color mode and export to CMYK, and make sure that all native objects have K-only color definitions. There are plenty of other considerations that need to be checked when producing press PDFs from within Affinity apps, so the issues related to grayscale are only one of the concerns (but one of the most frequently experienced, and confusing, probably much because the very different K/Grayscale approach/policy used in Adobe apps within CMYK/press-related production).
In this context, paying Adobe for Acrobat Pro -- still also available as a 32-bit app on a perpetual license, though I am not sure how it is made to be operable on modern macs -- is not money wasted. pdfToolbox by callas software would be an alternative (still more expensive than Acrobat Pro). Free Packzview is not a prepress tool but is useful for decent preflight (it appears to be generally available only for professional use, though).

You cannot produce grayscale (8-bit) PDF/X-based PDFs using Affinity apps. All forms of color definitions (RGB, Grayscale, CMYK) will be converted to CMYK disregarding the target color mode selected at export time, whenever PDF/X-based export method is used. 
Technically PDF/X-3 and PDF/X-4 would allow ICC-based gray to be exported, and this is what happens if you do this from e.g. InDesign. But when done in Affinity apps, your definitions of gray and black will always be converted to rich black (four-color black).
You can produce grayscale PDFs based on Gray/8 document, but then you need to use non-PDF/X-based export method and explicitly export to Grayscale (and define your black/gray either using Grayscale or RGB color model; K100 will basically be converted to RGB and then presented as a converted CMYK value).
If your printer requires a PDF/X-based print PDF, you need to switch the document color mode to CMYK and then specify your blacks and grays using CMYK color model, and K-only values. The PDF output will be basically CMYK, with CMY 0 and with K-only values. Grayscale images that you place, will by default have "K-Only" button (available in context toolbar) applied, and will be exported as grayscale images. 

Note that you could export PDF/X-3 or PDF/X-4 based Grayscale PDF also from Affinity apps, but you need to have a true grayscale print profile installed on the system (I am not sure but on macOS you might have Generic Gray inherently available [UPDATE: Checked, and Generic Gray Profile is inherent on macOS, but is not available whenever using PDF/X-based method]; on Windows [UPDATE: and on macOS, too] you would need to fetch one from the Internet, or have one that comes with QuarkXP or Adobe available), since the only grayscale profile that comes with Affinity apps (Greyscale D50) is basically a display (Gamma) color profile and not selectable when you have a CMYK or Gray/8 document color mode and convert to Grayscale, and use PDF/X-based export method:
 
If you leave the profile empty (or do not have anything available), all the blacks defined above would be converted to four-color black and have Affinity app default U.S. Web Coated v2 marked as the output intent profile. If you do define a true grayscale color profile as output intent, RGB 0,0,0 and B:0 (Grayscale 0) will be output in ICC-dependent 100% Gray (CalGray/ICCBasedGray), but K100 will have something like a 92% value.
See below a PDF/X-3 with no explicit press-specific grayscale output intent (U.S. Web Coated v2 auto-assigned):
pdfx3_gray_from_cmyk_noexplicit_output_intent.pdf
...and a version where a true grayscale output intent is defined:
pdfx3_gray_from_cmyk_quark_genericgray_output_intent.pdf
UPDATE: The same applies to PDF/X-4 production (and in PDF/X-1a only CMYK color mode is available).
If you do not have to use PDF/X-based export method, but force the Grey color space, the default Greyscale D50 would be available, but then, too, K100 values would have non-100% gray values. So whenever forcing grayscale output, you need to have native color values (text and shapes) defined either in RGB or Grayscale, not CMYK.
There might be point in checking whether the printer truly needs PDF/X-based output in grayscale, or whether they just meant K-only output (but accept any regular non-PDF/X based CMYK-based output, as long as CMY plates are empty).
UPDATE: And if they just meant K-only, then the correct method to produce such PDFs is to choose CMYK document color mode and export to CMYK, and make sure that all native objects have K-only color definitions. There are plenty of other considerations that need to be checked when producing press PDFs from within Affinity apps, so the issues related to grayscale are only one of the concerns (but one of the most frequently experienced, and confusing, probably much because the very different K/Grayscale approach/policy used in Adobe apps within CMYK/press-related production).
In this context, paying Adobe for Acrobat Pro -- still also available as a 32-bit app on a perpetual license, though I am not sure how it is made to be operable on modern macs -- is not money wasted. pdfToolbox by callas software would be an alternative (still more expensive than Acrobat Pro). Free Packzview is not a prepress tool but is useful for decent preflight (it appears to be generally available only for professional use, though).

You cannot produce grayscale (8-bit) PDF/X-based PDFs using Affinity apps. All forms of color definitions (RGB, Grayscale, CMYK) will be converted to CMYK disregarding the target color mode selected at export time, whenever PDF/X-based export method is used. 
Technically PDF/X-3 and PDF/X-4 would allow ICC-based gray to be exported, and this is what happens if you do this from e.g. InDesign. But when done in Affinity apps, your definitions of gray and black will always be converted to rich black (four-color black).
You can produce grayscale PDFs based on Gray/8 document, but then you need to use non-PDF/X-based export method and explicitly export to Grayscale (and define your black/gray either using Grayscale or RGB color model; K100 will basically be converted to RGB and then presented as a converted CMYK value).
If your printer requires a PDF/X-based print PDF, you need to switch the document color mode to CMYK and then specify your blacks and grays using CMYK color model, and K-only values. The PDF output will be basically CMYK, with CMY 0 and with K-only values. Grayscale images that you place, will by default have "K-Only" button (available in context toolbar) applied, and will be exported as grayscale images. 

You cannot produce grayscale (8-bit) PDF/X-based PDFs using Affinity apps. All forms of color definitions (RGB, Grayscale, CMYK) will be converted to CMYK disregarding the target color mode selected at export time, whenever PDF/X-based export method is used. 
Technically PDF/X-3 and PDF/X-4 would allow ICC-based gray to be exported, and this is what happens if you do this from e.g. InDesign. But when done in Affinity apps, your definitions of gray and black will always be converted to rich black (four-color black).
You can produce grayscale PDFs based on Gray/8 document, but then you need to use non-PDF/X-based export method and explicitly export to Grayscale (and define your black/gray either using Grayscale or RGB color model; K100 will basically be converted to RGB and then presented as a converted CMYK value).
If your printer requires a PDF/X-based print PDF, you need to switch the document color mode to CMYK and then specify your blacks and grays using CMYK color model, and K-only values. The PDF output will be basically CMYK, with CMY 0 and with K-only values. Grayscale images that you place, will by default have "K-Only" button (available in context toolbar) applied, and will be exported as grayscale images. 

This looks like a bug...
With the Layer (Capital L) selected, exporting to SVG results in the following output when Area is set to:
Whole Document - Some areas will be rasterised
Selection Area - Some areas will be rasterised
Selection Only - Some areas will be rasterised
With the layers (Small L) selected, exporting to SVG results in the following output when Area is set to:
Whole Document - Some areas will be rasterised
Selection Area - Some areas will be rasterised
Selection Only - Nothing will be rasterised
While this means that selecting all the layers (Small L), with Area set to Selection Only will export @BioWeb's file without rasterisation, it will at the same time strip the Blend Modes since they're not supported...

Blurry SVG.mp4  

Ok thank you Lacerto.  

Hi @Ben in Texas,
In lack of GREP styles in Publisher, you can manually use RegEx in Find Replace and either of these two search criteria:
\<(\s?(\S+)){2}$ or
.\S+?$ and then have "No break" as formatting in Replace field, to force at least two words in the last line.
There was once a longish discussion on the forum of usefulness of this kind of feature (if it could be applied automatically). as there is no paragraph composer in Affinity Publisher that could balance problems resulted from automatically applying this kind of a rule.
Here is a clip that demonstrates the difference of the two RegEx clauses (the latter accepts a hyphenated word as a word on the next line, the former requires two complete words; there was a mistake in the original post). The clip also demonstrates the benefit of having a paragraph composer calculating dynamically changed word wrapping (as far as I know, only available in Adobe apps):

Single_vs_paragraph_composer.mp4  As mentioned, the feature cannot be applied as a paragraph style (in Affinity Publisher), but with the improved Find Change it can be applied selectively to specific scope and confirmed one-by-one, so potentially useful, and at least as an exposer of runts.

I once wished an option that would either require input focus before performing mouse-wheel based value adjustment, or alternatively, e.g. 500ms delay within a certain hover delta tolerance that would be enough to indicate that wheel was scrolled to adjust a value. I have learned to beware of inadvertent value adjustments but it still happens occasionally. It is fine to have it operating as it does now, but this kind of an option would be welcome.

I once wished an option that would either require input focus before performing mouse-wheel based value adjustment, or alternatively, e.g. 500ms delay within a certain hover delta tolerance that would be enough to indicate that wheel was scrolled to adjust a value. I have learned to beware of inadvertent value adjustments but it still happens occasionally. It is fine to have it operating as it does now, but this kind of an option would be welcome.

Yes, that was a right royal pig not being able to search to the bottom! I'm going to really use Libre Office in future, so thanks for the great tip. For now your work on the document saved the day and I've now gone and published.

An afterthought: This was a really interesting problem because Apple Pages could basically fix issues with a broken Word (its ability to autoaccept table changes and control so well Word tracking is a powerful feature and makes Pages a valuable Word document tool). It is also interesting that it seemed to be able to handle numbered paragraphs so well. Without having the original Word document, it is difficult to say what actually caused the numbering chaos in Publisher (e.g., losing the number formatting). As mentioned, InDesign imported the sample Word document better but it was necessary to redefine the heading styles there, too. Yet the .docx file exported by Pages appeared to behave correctly in Word. 
EDIT: I forgot to mention that I seem to have found a bug in the UI of macOS Publisher when trying to Find Replace heading styles. When there are lots of styles, it is not possible to scroll hidden styles visible similarly as it is on Windows where there is an arrow at the bottom of the list and where the mouse wheel can also be used to scroll these kinds of lists. I could not find an alternative method of having formatting style added in Find and Replace boxes so I did this task in the Windows version.

scrollingbug.mp4 EDIT: I realized that it is possible to use arrow keys but it is of course pretty awkward...
UPDATE: Actually LibreOffice Writer could also be used to fix the Word document [accept all changes and stop tracking] and when saved back to Word format, the numbering problem was also fixed [but only when importing to e.g. InDesign; Affinity Publisher appears to have bugs in importing lists]. There was List Paragraph style that had alphabetical list style removing of which fixed the insanely long lists in a snap, but there are probably paragraphs where this list styling was intentionally applied so careful revision job is needed to make this document work as expected. 

@lacerto Good catch! Thank you. I'm on a 2017 MBP using an Intel Processor and I found that rgbtoi works for me too if I turn Metal acceleration off. Just wanted to confirm this is the case with Intel Silicon, so the developers have this info. I haven't retried the Voronoi (cellnoise) function yet, but I may do so. 

@lacerto Thank you, Lacerto. That definitely works.
I came up with an alternative solution until "rgbtoi" and other PT functions are fixed in v2.4. I hard-coded 30%R, 59%G, 11%B into the formulas for each individual channel. As long as the a,b,c and d variables are set to zero, I get a straight BW conversion, since all three channels are identical. This results in a BW conversion which is indistinguishable from Channel Mixer (with CM set to grayscale). The a,b,c,d variables are for toning and brightness control. They allow me to adjust the color of the individual channels (by eye). The "d" variable allows me to control the overall brightness. I made that brightness adjustment "d*2" in the formula to allow for a much wider brightness range when working on dark images. So, this way, I don't have to worry about the position of the sliders to achieve a neutral tone. 
The slider settings of +17R and +20Y below give a warm yellow-orange tone to the image. I created a bunch of "Value Presets" for different tones. I wanted to use the rgbtoi function, but this works okay for now. 
Thank you!! 

I meant that there is same kind of inaccuracy also in VectorStyler native shapes as regards snapping, but typically only at these kinds of zoom levels:

This means that snapping indicators tell that there is perfect snapping (collision of not just arcs and two kinds of ellipses it can draw, but whatever objects...), while there is still this kind of microscopic gap that has no meaning in graphic design.

You’re welcome.
I don’t have VectorStyler so I can’t repeat that workflow but I guess it might depend on how VectorStyler internally handles ellipses.
If it handles them differently to the Affinity applications – e.g. single curve surrounding two focal points, instead of multiple bezier curves –  then that could account for the difference. (I’m fairly sure that this has been discussed elsewhere in the forums, probably a number of times.)
As you say, the difference is usually so small that it doesn’t matter for illustration purposes and, in my opinion, if someone really needs to do precision drawing then they should probably be using CAD software rather than illustration software (although, of course, that doesn’t mean that the illustration software cannot be improved in the future to be as precise as CAD, in this area at least).

Only by using third party software like this one. The good news is that you can relatively easily copy and paste basic vector objects between both apps via the clipboard.