I must credit sipa as first raising this issue as far as I know.
If we did the obvious thing and used [a current OP_NOPx] for OP_EVAL, then, surprisingly, OP_EVAL would not necessarily cause a block chain split.
There's a bit of a problem with rolling out OP_EVAL using this idea and I believe it may create a more dangerous block chain split than casascius' alternative proposal whereby OP_CHECKSIG gets renamed and re-imagined as a slightly hacked OP_EVAL.
It's true that old clients will be accepting of blocks creating and spending OP_EVAL transactions. This is the advantage you mention.
However, old clients will also be accepting of blocks which contain transactions which incorrectly attempt to spend OP_EVAL transactions with a null scriptSig. As you mentioned in the IRC, the old clients see these OP_EVAL transactions as ones which anyone can redeem.
Miners would be best placed to watch out for transactions in which a null scriptSig can satisfy the scriptPubKey and then include transactions spending them in their blocks. This checking could be implemented now in anticipation of OP_EVAL being introduced in the fashion you propose and the exploit could be fully automated and require no time-consuming user intervention. This means that the bitcoin developers would have little time to react before the fraudulent transactions become confirmed. Clients (and miners) using the new version would reject these blocks but they would at least initially be a minority. People may opt not to upgrade to the new client as it would be easy to portray the new client's behaviour in negative terms. The effect of the above exploit would be to have a block chain split in which the latest clients who are supposedly doing the right thing may end up on the losing side. It would be bad for the public perception of bitcoin if an upgrade voluntarily precipitated a completely optional disaster along these lines.
I think it's more practical for people running old clients to bear the risk of failing to keep their software current. The policy towards incompatible changes will have to decide how much risk is acceptable and how long a time users are guaranteed to be safe running a particular version.
Bitcoin is lacking an effective and reliable mechanism for safely performing block chain splits. The worst-case scenario is one in which mining pools say they have updated their software and patch their clients to look like they are updated but then their software is actually designed maliciously to exploit the incompatibility of the new clients. If a client deployment strategy can cope with this situation then it can probably cope with anything.
Before introducing an incompatible client, I think it's wise to ensure that the existing clients have robust detection of block chain splits.
In particular, if a client sees a succession of what it thinks is invalid blocks with a high difficulty, then instead of banning the peer for misbehaviour, the client should disallow transactions (until overridden) and advise the user that an upgrade may be required.
Another way to limit the financial damage from an exploited rollout would be initially only to allow new incompatible transactions of infinitesimal value; where both the transaction
and any change are both suitably small. This limit would increase in some fashion over time unless perhaps a "shutdown" transaction were broadcast which would disable the new behaviour. This shutdown switch could be removed in a subsequent version when no exploits appear and sufficient confidence has been reached. Also, there would have to be an initial prohibition against spending new style transactions into old style transactions.
Also, instead of enabling a feature after a certain block number, it could be introduced after seeing a block containing a particular magic transaction. This protects against the situatuion in which the miners (or the rest of the network) fail to upgrade as quickly as expected.
ByteCoin