Reading through your post, it looks that there is no template matching, it is verification without interpreter. The fake BIP322 transation is to be verified! A client without the interpreter! People have hell of a job to support it, don't they? Very few are invited to this party, I suppose.

It is not the way you design software, seriously. It is just contingent dependency, we need the message to be signed explicitly, otherwise we are dependent on this verifier.  Now, check a real template based solution and compare the elegance and beauty:
We have three parties: the signer, the verifier and the consumer.

The signer:
 already knows which address should be used, it signs a message with keys for the address, then it attaches the address the script behind it (if any).

The verifier:
First and foremost, checks whether signature is correct per se. If passed, the message is authenticated, but it continues checking if the signer has included supplementary, bitcoin blockchain related info, if so, it compares the address received directly or extracted from the supplied script (template based), comparing it with the keys used, if passed, the address reference is attached to the message.

The consumer module:
Has a signed message with public keys disclosed and a reference to a bitcoin address for profiling purposes and as a metadata.

Such a signed message is independent of bitcoin-like clients/modules, standing on its foot, it is self-contained.

Note that we have a total different scenario here with what Greg Maxwell has proposed:
Here the signed message is the core data, relation with bitcoin is metadata. Greg has put it upside-down because in the real world, we focus on the message. If this up-side down world has an excuse to exist, who am I to oppose, what I'm insisting on is to do it separately and in its own application domain (being a very narrow domain, I suppose).