EOF is not a new version EVM. It is a container format around the existing EVM model and a number opcodes to fix several issues related to technical debt: static jumps, code validation, subroutines, removing code introspection, and removing gas introspection. The core model of the EVM remains the same, and Legacy EVM and EOF can freeley call each other with the exact same semantics. Your traces will look mostly the same (new opcodes aside) and the same techniques you use to develop will be the same. To most smart contract developers it will be nothing more than toggling a switch in solidity or vyper, and your code will also be a little smaller once you do.
The biggest immediate advantage that EOF unlocks it the ability to safely uncap or significantly raise the smart contract size limit (but the block gas limit will always be a mainnet cap). Because of JUMPDEST analysis we have to limit the sizes or open the legacy EVM up to significant DOS attacks. Code validation fixes this.
As for the legacy EVM, deprecating it is totally in my roadmap. But first we need to get EOF out and used before we can ramp up discussion about deprecating new deployments and examining ways to migrate legacy EVM code, if such migrations are required. This would start with closing off deployments of new legacy contracts, or possibly making them progressively more expensive. I see this only ocuring at create transactions, factory contracts (like pools) would necessarily remain as-is.