each implementation of bitcoin should have a way of producing and verifying ECDSA signatures and work with scripts to some extent (usually standard ones only) but they don't have to have the flags used in bitcoin core specially when it comes to message verification. for example none of these exist in SPV clients such as Electrum so their code has to significantly change if they wanted to implement this I.P.:
SPV clients don't verify transactions-- they can't because they don't have access to scriptpubkeys. This means that I wouldn't expect SPV clients to already contain the relevant code.
also these flags are used during block verification and most of them are there for backward compatibility (eg. whether BIP-66 is enabled to use DERSIG or BIP-112 for OP_CSV), i don't see why they should be used in a message signature verification.
Yucky for the spec to be described in terms of those flags which are presumably not adequately documented.
But the behaviour they signify has to be handled correctly to use generic Bitcoin addresses to process messages.
not to mention that certain things from bitcoin scripts can not even be imported into message verification. some are addressing malleability issues, some OP codes such as those involving locktimes cause a lot of problems as there is no transaction or block to use for verification, the "signature" that is popped from the stack in transaction during script evaluation has a sighash flag which makes no sense in a message since there is no txout/ins to sign based on that,...
The strategy there should be to operate with a dummy, and the spec should be describing it that way.
take P2PKH and P2WPKH, both of them are the exact same thing there is a pubkey that is hashed using HASH160 and there is a signature that matches that pubkey. in a transaction it makes a difference when creating the hash digest for verification and where the "stack items" are placed, but it is the same when verifying a message.
same with P2SH and P2WSH.
That sounds like just falling into the same trap of only supporting an absurdly narrow subset of keys users use which then stands in the way of new use cases. I think that's just a total waste of time, and actually harmful for the industry.
For example, there have been users that refused to change to multisig-- when they could have otherwise used it, because they couldn't signmessage with it and they'd adopted some workflow that required them to signmessage with their addresses. The old signmessage format has turned out to be a boat anchor that has actually slow the adoption of new techniques and better security in Bitcoin. In hindsight, I think we made a mistake in ever implementing it in the first place.
There is certainly a place in the world for message signing systems that are simpler and less -- well-- weird than Bitcoin script but for those you should use something like PGP or signify.
And I don't intend to defend the BIP322 specifics -- only the general motivation of using script so that you can sign with arbitrary addresses.
It's not done that way because the authors wanted to use some bitcoin core internals, it's that way because its intended to be a generic mechanism that works for _every_ address, unconditionally, even ones that aren't widely in use right now-- and can be easily extended as bitcoin's consensus rules are. The easiest way to do that is to use a bunch of bitcoin internals, but it sounds like it's currently resulting in an unclear spec. -- apparently unclear enough that it didn't make its motivation and justifications clear enough.
Inherently though, anything generic is going to be more work to support for something that doesn't actually support verifying bitcoin signatures. There really isn't any way around that-- but fortunately no one is required to implement it!
