Initially, another OP_SUCCESS code was considered but was replaced by 0xcb to sidestep conflicts with BIP345. The discussion highlights a concern over reusing the term OP_PUBKEY, given it was not an actual opcode in the past, suggesting that repurposing this term could lead to confusion rather than clarity.

The email outlines a specific use case related to creating a stack of public keys accessible sequentially within a script, identifying only the taproot internal and external keys as relevant for such functionality. It points out that any additional keys would be explicitly included in the scripts undergoing validation, thereby limiting the necessity for a more complex handling of multiple keys within the script's logic.

Further contemplation is given to an alternative opcode design dubbed OP_TAPKEY, which could be invoked twice within a script to push both the internal and external taproot keys onto the stack. The sender expresses a preference for having separate opcodes for each key to enhance the ergonomics for script developers, rather than a single opcode capable of pushing both keys but potentially causing script failures upon subsequent calls. An additional suggestion includes the creation of an OP_TAPKEYS opcode designed to push both keys at once, allowing the script to discard the unnecessary key, thus simplifying the process and improving script efficiency.