In Pieter Wuille's recent answer [Why did BIP-342 replace CHECKMULTISIG with a new opcode], BIP-342'sdeliberate minimization of semantic changes was attributed to theexpectation that "those could always be introduced with later softforksthat redefine OP_SUCCESSes."I'm curious about the granularity of this reservation:Were specific opcode candidates (e.g., CHECKSIGFROMSTACK, CAT, TXHASH)already on the radar when OP_SUCCESS positions were allocated, or wasthe allocation purely abstract — "reserve space for unknown future use"?Was there discussion about classes of additions (introspection opcodes,signature variants, hash operations) that would or wouldn't be appropriatecandidates for OP_SUCCESS redefinition vs. requiring a deeper softfork?Are there design properties an opcode SHOULD have to be a cleanOP_SUCCESS redefinition (vs. requiring more invasive consensus changes)?I ask because the activation-path mechanics matter for how communitydiscussions about future opcodes should be framed: is the conversation"which opcode" or also "which opcode reservation slot."