This would benefit from changing the code a bit more, but in more elementary steps.

The description of the diff has now gone completely off rail. It start by discussing philosophy and then goes on to explain what not to do. That's a good sign that you are not focused on what you should be doing but on abstract matter that do not matter. Case in point the script red a json and output a json with the same infos in it, but in a very complex and highly specialized manner - which goes completely against the UNIX philosophy, BTW. Either you want to do a tool that fetch things from the RPC and output them in JSON (hint, that's bitcoin-cli) or you do something that extract the relevant infos and put them in a form that's usable. You can even drop the pretense of being a UNIX philosopher and do a script that does both at once.

bitcoin-cli clearly doesn't need the node to be started with custom parameters. So why is it required here?

rebase

The test plan doesn't test the feature. For all we know this could fail to extract the proper value for chain work and just copare to zero or something and you wouldn't know it.

Call it SCHNORR_MULTISIG or something. New multisig is a great name up to the point we need a new new multisig.

rebase and fix details to match the PR better

rebase

Rebase

This is the type of PR you typicaly may want to backport in one piece to reduce the work involved.

Rebase

Revert prevector_tester ctor.

No change for tests?

Rather than grepping and replacing within the script, you could simply generate a header that is 100% generated by the script and defines a few constants that then get used in the chainparam code. You'll get a more robust design and people won't get merge conflicts with a bot.

This makes the code more semantically driven. Me gusta :)