@Russell I think there were sound arguments against Satoshi's statement made in that very thread. Especially that software can be written to warn the user about edge cases.
If a person waited for the standard 6 blocks before accepting a transaction as confirmed, there should be no significantly likely scenario where any finalized transaction needs to be reverted. If 6 blocks is indeed a safe threshold for finalization, then any transaction that has 5 or fewer confirmations should be considered fair game for reversal. I don't agree that this is "unfair". In fact, I think that's pretty standard, is it not? Any chain of transactions that happen in the span of 5 blocks shouldn't be doing anything that expects those transactions to become finalized until the relevant transactions get 6 confirmations.
I don't think the possibility of buggy software is a good reason to block an opcode. Not that I'm hankering for OP_BLOCKNUMBER specifically. However, I think there are good use cases for spend paths that expire (eg for more effective wallet vaults).
I've come across this argument before, and it seems kind of like Satoshi's word here is held as gospel. I haven't heard any deep discussion of this topic, and I even asked
a question on the bitcoin SE about it. Sorry to hijack this conversation, but I'm very curious if there's something more to this or if the thinking was simply decided that OP_BLOCKNUMBER wasn't useful enough to warrant the (dubious) potential footgun of people accepting sub-6-block transactions from a transaction that uses an expired spend-path?