But why would you have a new opcode if there is already an existing "legacy" sequence of opcode that you can use to emulate it? The new code would either not be able to do something new or it would cause a split. This also smells like vulnerabilities like getting the two split nets to do different things. And as nobody is using scripts anyway this is currently not needed.
The idea is
Old Clients
Legacy code: Accepts
New code: Accepts, but only if in mined blocks
New Clients
Legacy code: Accepts
New code: Accepts if it is valid under old and new rules
If 99% of the nodes are new clients, then splits aren't likely and will correct automatically.
The old client won't incorporate transactions which contain the new code. This means that it will never create a bad block according to the new rules.
If a new client creates a block that meets the new rules, the old client will accept the block.
There is no conflict between the 2 and the chain stays unified.
If an intermediate old client was to try to incorporate a script that fails according to the new code, the all the new miners would refuse to accept it. This fork would last only a short time. Once the 99% of the process power has generated 2 more blocks, that will be the main chain again.
The key point is that any script which is valid under the new rules is also valid under the old rules. However, the new nodes will reject some blocks that would have been valid under the old rules. This is why it is important that they have > 50% of the processing power before the rule is used in general.
