I think adding upgrade hooks, as he says, is pretty fraught, vs “just use another opcode”. Currently if someone reorders it, it just becomes trivially true do the hash type has to be committed to in the output to avoid “anyonecanspend” style behavior.
Thanks for bringing this up. As a rule, I think the <argument> OP_TXHASH should be treated as a single fragment, each of which has exactly one interpretation at each soft fork level. In cases where a script wants to accept a signature on several possible TXHASHes they should explicitly guard the opcode as I now show.
I do think that the benefit of upgradeable OP_TXHASH is more important than the ability to easily specify the hash type at spend time or compute it in script. My first thought here is that this is potentially a correct disjunction between the existing sigops and OP_CSFS: Existing sigops allow for safe spend time hash method specification because they combine the hashing and signature checking. Once the hashing operation and signature validation are separated the hash method should be specified in the output. This relates to the reason that bip118 settled on using a new key type. Existing key types hadn’t pre-committed to being spendable with the new modes.