Do you disagree it is useful abstraction?
For sure, if it holds any water, it would be poisonous, imo.
A template-matching based verifier will only be compatible with a subset of potential BIP322 signatures, reporting "inconclusive" for others.
NO! It will be incompatible with ALL BIP322 generated signatures and vice versa, They belong to two different worlds and only with lots of dependencies and ugly stuff can agree upon a message being signed: you need to generate and sign a template friendly message then put this message in BIP322 virtual txn then again sign it!! lots of other ugly details here.
The question is: why should they communicate ever? One being a conventional message signing algorithm, the other being a special proof-of-authority "thing".
But even if *all* implementations use just template-matching based verification, this approach still has the advantage of defining a single format that is compatible with *all* potential future extensions that correspond to script features. Because addresses are encodings of scripts, and what we're signing for is the ability to spend outputs sent to a certain address, using script for the message signing too is just the obvious match in my view.
In my view, it is a too long shot which ends in a total miss-fire. There is no reasonable way for circumventing the versioning requirements when you add features, trust me, it will never happen, there is no general solution for all the problems. Soft-forks do not happen in bitcoin on a daily basis, it is not a "project", like what Etherem is, so, it'd be easy to add new templates ever few years or so.
I believe it is entirely uninteresting to work on any kind of message signing system that is restricted to a subset of what script can do. That is postponing another inevitable future problem again, when that subset no longer suffices.
With all due respect, Peter, you need to re-think this approach. You are free to implement your script version and promote it as whatever you wish.
I'm serious, it is useful, but as far as it is not introduced as a signing mechanism, hence "postponing" the development and implementation of a standardized template based (universal) signing system.
The interpreter based system you suggest is good and useful, but in its own domain and universe, for its own (future?) applications.