Support for legacy files and programs in newer relases of an OS is similar to the "clean fork" approach that I described. namely, the new software is aware of the old sematics and can use it when required. Any hard fork must have such backwards compatibilty, because it must recognize as valid all blocks and transactions that were confirmed before the fork.
You could just checkpoint the block where the rule change happened and then just include code for the new rules. The client would still need to be able to read old blocks, but wouldn't need to be able to validate them.
Checkpoints aren't very popular though and takes away from claims that everything is p2p.
I meant to point out that there is no way that a client can make sure that an unconfirmed transaction will ever be confirmed, even if it seems to be valid by current rules. Everybody agrees on that.?
In fact, there is no way to put a probability value on that event, even with the usual assumptions of well-distributed mining etc. Everybody still agrees?
I disagree.
If you create a transaction that spends your own outputs, then it is possible to be sure that that transaction will be included in the blockchain. You might have to pay extra fees though (assuming some miners have child pays for parent).
A rule change can make the transaction invalid and that is a reason for not making those rule changes.