I would further add that if you search the forum here for “processing pane” and “post-processing” in the post-2017 timeframe, you should find a number of good discussions on what sort of automation the compiler supports, and how one can even go about creating their own bespoke file format generators. In fact the Non-Fiction-LaTeX project template that ships with the software was built in part not only to facilitate demand for a native LaTeX workflow that did not require learning Markdown, but to demonstrate how Scrivener can be configured to generate complex plain-text file formats with no inherent knowledge of them.
And that project does not even dip into post-processing (outside of one very simple example script that could, when enabled, make the compile process go from producing a .tex file to a finished .pdf file).
You will also find practical examples of automation on the forum, for example this multi-file compile setup.
Abandoned the old compile settings with no mechanism for upgrade
Well that’s strange. This is what you were asking about initially, and the document that Katherine provided to you answers precisely how to upgrade your compile settings. I realise you have rather hotly declared that the tutorial does not address this, but I would suggest you give it another try.
This is even one of the bullet points on the page that has the download link!
In fact almost all of the compile settings will be updated if you import them from the project, or from your previous repository of compile presets.
As much as I liked using Scrivener in the past, it seems you’ve gone out of your way to ensure it’s unusable for technical writing.
If you say so. Fact of the matter is though, Scrivener 3 has a programmable compiler that is capable of constructing most forms of syntax directly (we used XML as a target benchmark for how detailed we wanted the conversion process to be capable of).
But whatever! Despite all of that, the ancient v2 system that couldn’t even handle a simple tagged text range and convert it to <something>here</something> was better. 
In conclusion, I would be happy to help you figure out how to get your workflow going with the new system. You may find a lot of it no longer needs to be in exterior scripts, and what scripting you do need may even be something you can pack into the compile settings themselves, making distribution to your users a snap. No installation instructions, no shell commands.
Might want to dial back the righteous fury a bit though, so that we can actually discuss things instead of spending time on paragraphs such as these.