BIP 118: what specifically made opcode-level alternatives "more complicated"?

External question — Bitcoin Stack Exchange Author: Aaron Zhang Original post: https://bitcoin.stackexchange.com/questions/130701 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. BIP 118's Motivation section says: "Possible alternative approaches would be to define new script opcodes, to use a different taproot leaf version, or to use a different set of SegWit outputs ... however all of these approaches are more complicated, and are better reserved for other upgrades where the additional flexibility is actually needed." What specifically made opcode-level alternatives (e.g. a hypothetical OP_CHECKSIG_ANYPREVOUT) more complicated than the chosen pubkey-type approach? Was it spec effort, implementation effort, or consensus surface area? I'm asking because, in light of recent CSFS (BIP 348) and CAT (BIP 347) discussions, the opcode path now seems tractable. Curious how the original trade-off was reasoned at the time.