I thought I'd transplant Gavin's post to here, rather than derail the original thread.
Here is the timeline I've proposed in BIP 0012
Now until Jan 15, 2012 : miners update their software, start including CHECKMULTISIG and OP_EVAL transactions in blocks they mine, and indicate support by including the string "OP_EVAL" in the blocks they produce.
Jan 15, 2012: we assess support for the new feature by looking at the percentage of blocks that contain "OP_EVAL". If a majority of miners are not supporting it, then deployment will be delayed or cancelled (a setting in bitcoin.conf controls the switchover date, with the default being Feb 1, 2012).
Feb 1, 2012: assuming there was majority support on Jan 15, OP_EVAL is fully supported/validated.
Using your link for BIP 0012, I didn't see any reference to a timeline.
Found it. It could be more prominent.
What's the timeline for enabling relaying of OP_EVAL transactions and for a client that can generate OP_EVAL transactions?
Also, when will clients be patched to start rejecting blocks with the OP_NOP1 interpretation of OP_EVAL?
I presume that, if all goes well, then on the 1st of Feb 2012, blocks containing OP_EVAL will suddenly be interpreted in the new stricter fashion than when it was OP_NOP1. We know that GetTime() seems to return widely disparate results over the bitcoin network. Are we confident that problems are not going to arise because of the pseudorandomly timed nature of the change of interpretation of the opcode?
This is why I suggested a magic transaction in a block to precipitate the changeover.
Majority hashpower support for OP_EVAL is required before changeover. It's conceivable that something might go wrong after OP_EVAL transactions are mainstream which might make miners revert to interpreting OP_EVAL as OP_NOP1. If OP_EVAL loses majority hashpower support then the bitcoin system keeps going but with considerable damage to reputation, prospects and some people's wallets.
Has there been any consideration of this possibility?
I suggest that OP_EVAL transactions be limited to "toy" amounts of bitcoins until enough of the installed base of clients would reject the OP_NOP1 interpretation of OP_EVAL.