This is a reasonable idea - I’ll add it to the list. The main barrier is that it will require either a new consensus field for accounts, or some other means of communicating EVM versioning.
It’s worth noting that this doesn’t require two entirely separate EVMs, just some context that gets passed around for the current execution environment. Nodes already need most of this functionality to handle previous hard forks that have changed execution rules.
One way to handle this would be to introduce a new opcode, along these lines:
VERSION: Pops one element from the stack and changes the execution environment to the specified version. Clears stack and local memory before handing control to the new version, which begins executing at the next PC value.
Each new contract would then start with a prologue along the lines of PUSH 1 VERSION to enable the new EVM. This avoids the need to introduce new consensus data structures.
This can even be used for a transition to Web Assembly; contracts would just start with a prologue that switches the execution environment to EWASM.
Alternately, this could be a pseudo-opcode that’s only valid at the start of a contract, for simplicity reasons.