VERIFY is also important for upgradeability; if you don’t have the <32-byte-hash> parameter, you can’t make the opcode upgradeable.
Now maybe in a tapscript context that’s okay because you’ve got so much unused opcode space.
I’m not averse to it, I’m just trying to figure out why you want it, since all the uses of CTV I’m familiar with are VERIFYs - I gather it’s to make ln-symm more efficient or something? I’m not trying to be glib here, I just think the motivation for what you suggested wasn’t explicitly mentioned.
I’m totally fine with having adding a tapscript-only OP_CHECKTEMPLATEHASH that pushes the hash to the stack if it helps someone, that’s not a lot of marginal complexity. But I think the idea that it would replace CTV as-is is sort of a different proposal.
Again, not trying to be glib here but is there a more specific reason than “each reviewer has to review about 15 marginal lines of not-substantially-novel code?” What about legacy is so complicated that it really moves the needle?
I understand the argument that we only have so much NOP-space left, but given the bare CTV case is “most compact way possible to commit to n future spends,” I think it probably justifies the allocation.
Please grant me the goodwill to admit it’s a reasonable thought that if chainspace ever does become massively short, congestion control is a good escape hatch to have on hand - even outside of the use for miners today.