Legacy CHECKMULTISIG has FindAndDelete attached to it. SegWit v0 already removed FindAndDelete and kept CHECKMULTISIG working fine. So for tapscript, the simple path was: keep CHECKMULTISIG, say FindAndDelete doesn't run here.BIP-342 didn't do that. It disabled CHECKMULTISIG completely and added CHECKSIGADD, so multisig is now a sequence of opcodes plus a comparison.That's a much bigger change than just fixing the bug. I'd like to understand why.A few things I'm curious about:Was a "clean CHECKMULTISIG" ever considered, and why was it rejected?Was the main reason batch verification with Schnorr, or something else?Or was it a deliberate choice to move away from opcodes that pack whole patterns, toward smaller primitives that script authors combine themselves?The last one matters to me because if it's a real design shift, it probably also shapes how future opcodes (CAT, CSFS, etc.) should look.If anyone was part of those discussions, I'd love to hear the actual reasoning.Note: This is not about whether CHECKSIGADD could be retrofitted to SegWit v0 (that question has been answered — it can't, it would be a hardfork). My question is the opposite direction: when designing tapscript, why introduce CHECKSIGADD at all, instead of keeping CHECKMULTISIG with FindAndDelete removed?