The OP_EVAL BIP says that "Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases:
- An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners.
- An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners"
It sounds to me backward compatibility (avoiding situation 1) is more important than forward compatibility (avoiding condition 2).
Question: what would be the disadvantage of making OP_EVAL/p2sh/CHV a totally new opcode, so that any "old client" would immediately reject any transaction using the new opcode?
This would ensure that situation 1 never happens since all OP_EVAL/p2sh/CHV transactions are invalid for old clients/miners. Old clients/miners would reject new transactions they haven't been taught about, which is pretty much what you expect to happen when you upgrade your software -- old software might not be able to read data files created by newer software.
You might say "well, then we have to force all the clients to upgrade instead of just the miners"... but the alternative is basically transferring trust from the clients to the miners, so avoiding a client upgrade doesn't come "for free" even though it might seem like it at first.
Right now the clients do all their own validity checking of the blockchain and do not rely on the miners' validity checks at all. If 75% of the hashpower decided to change the validity rules they couldn't -- the clients don't rely on their checks. The clients (exchanges included!) would promptly proceed to ignore the mutinying miners. But OP_EVAL/p2sh/CHV end that clear separation: with "forward compatibility" we are asking people who use these new transactions to consent to a state of affairs in which old clients receiving coins from them will (unknowingly) transfer validity-check responsibility to the mining pool. Nobody seems to be talking about that.