According to the latest version of BIP322, a twin of bitcoin script interpreter
Not a twin or separate implementation, rather it
is the script interpreter. The implementation in Bitcoin Core uses the actual script interpreter used for actual script verification.
It is just true for Bitcoin Core, how is it supposed to be implemented by third party wallets and services, or maybe it is never going to happen, right?
verifies that a stupid, fake txn is supplied with appropriate witness data for unlocking its first input, which is a real outpoint of a real transaction, a message is supposed to be signed in this process, hence, 'tied' to the said outpoint. So, what this 'tying' implies?! Nothing! It has has no meaning without examining the witness data more closely by an intelligent app/human being, interested in questions like what follows:
Is there any actual signature? How many signers? Are the signers, if any, the sole entities able to unlock the outpoint under consideration? If No, are they primarily supposed to be the normal destination, or they are relevant because of a backup branch in the script?
Without specific answers to such questions, the 'tie' established by "script signing" is worthless, bears no information, applies to no real use-case.
That's true of the old message signing method too.
In the original message signing, you get a pubkey out at the end, not an address, a pubkey.
It is not a failure of our old friend, it is part of the specification. Tying transactions to signatures, is a new feature, adding new features is always possible, but specific measures should be taken both in the definition of the requirements and in the design process.
On the other hand, for now, this 'new feature' is suspected to be artificially invented for justifying the "sign-by-script" idea, where, as I've mentioned before, it claims:
Tying a message to a txo as metadata, is the only relevant application of message signing with bitcoin keys. Which is absolutely wrong:
First and foremost, this so-called 'tying metadata'(!) is not that important, if it is relevant at all, in the context of 'signing'. The common application is, and has always been, proving authenticity, data integrity and non-repudiability of a message, using bitcoin keys with a
possible reference to a txo in the blockchain, if the owner finds sych a reference useful. i.e., the main application is using bitcoin as a public key infrastructure. In the concrete world we are living in, (not the abstract world created by the above claim) signed messages are not supposed to be 'metadata' of a txn, signing is not binding anything to any other thing. It is just about authenticity and other characteristics we mentioned above.
One of the main use cases I've seen for message signing is to prove that a person has the ability to spend coins sent to the address. It doesn't matter which branch is used in the script to prove that because any branch can spend the coins.
it is not a use-case, just an imaginary scenario, projected from the solution domain to the problem domain, in an upside-down world. Interestingly, even this "use-case" is not fulfilled by the design:
I provide your application with a utxo reference and a proof bound to some message as being a "sign-by script" BIP322, convincing it, your app. that I'm able to unlock the said utxo, right?
Now what? Your application decides to give me a credit or something, either with respect to or ifnoring the content of my message? Who am I? The one who provided the proof? How this scheme is supposed to resist a simple man-in-the middle attack? What happened to authenticity? What about non-repudiation?
About branches being irrelevant the way you put it:
I'm afraid, you are missing the point; Once you abandon the original meaning of signing a message in favor of "tying metadata to a txo", by using scripts instead of keys, you have no choice other than processing/using this metadata, someday, somehow (otherwise it deserves no label other than "absurd"), hence you need to know how viable this metadata is, and how exactly the unlock process has taken place.
The point being that, you have no clue about the script under consideration, you shouldn't have such a clue, the whole scheme falls apart with such a dependency. It is why this scheme never works as a general signing mechanism, it is a dependent, application specific, utility which by no standard is supposed to be called a "signing" mechanism. It has nothing to do with signing per se.
Please stay focused a bit more, it is just the beginning of my criticism:
Even the loose defined concept of "binding metadata to UTXOs" being considered a serious application, it doesn't force us to adopt BIP322!
Engineers would merge it with established ES concept, (making lemonade with the lemon) by applying 3 constraints:
1- Restricting the problem domain to well-formed, standard scripts, either built in or external.
2- Restricting the message to be well-formed in an application specific sense, though.
3- Enforcing general compatibility of the metadata under consideration to be authenticated, non-repudiable, integrated using a supported ES scheme with explicitly distinguished public key(s).
Now, it'd be easy to implement without ruining everything in the name of generalization or abstraction, one should take care of such practices not to go excessively wild, turning to be useless and absurd.