Virtualization requires that you have a complete copy of the entire OS running, and all code execution is opaque to the host. That means all execution of code is just in time - because it's not native - and you can't have any part of virtualization running optimized arm code - because you're in a virtualized x86 box.

Translation on the other hand involves basically parsing the object files, finding entry points, translating those, and then occasionally jit compiling when the code was doing something funky so your entry points were wrong (think obfuscation, compilers written the night before a compiler assignment was due :D ). And of course JITs themselves.

JITs (especially self modifying ones) are a particular pain point for all engines be they virtualization or translation, because they necessarily require you to recompile or invalidate pretty much entire pages of compiled code. Unfortunately virtualizing a machine with a different instruction set gives you an opaque view of what is happening so takes all executed code far closer to the JIT/interpret only end of the spectrum.

So the end result of this is you get a much because resource impact - you've loaded a full clone of the OS on a virtualised machine, so you may not even be able to leverage hardware virtualization support (I imagine with some skullduggery it could be possible), and even if you could you now have duplicate page tables as well. Then you have the perf impact which is because the outside environment is opaque to the VM you lose a lot of your ability to rely on code not changing, or to perform any AOT work.

Now some of these may be mitigable, but at some point you have to ask why you would bother when translation has lower resource usage, higher performance, and can be made much more seamless.

Its a whole different ball game. The current solution recognizes Mac system calls and routes them (maybe with some exceptions) 1:1 to the host OS, so there is a single OS that knows all what’s happening in the system.

If you have two OSes, it gets complicated. You have two virtual memory maps, two structures tracking open files, two disk caches, two clipboards, two networking stacks, etc.

As an example, if an application on the guest OS tries to open a file for exclusive access, the guest OS checks it’s data structures to see whether that’s possible. That’s insufficient, as the file may be open on the host OS. Similarly, the guest OS may cache writes to a file, and the host OS won’t check the guest OS’s disk cache when an application on the host OS reads from that same file.

So, you either make that impossible by giving the guest OS a disk for its exclusive use (could be a virtual one), or you provide ways for the two OSes to co-exist on the same hardware. That can be made to work, (but isn’t ideal; copying files between the two OSes would be cumbersome) for disks, but is too impractical for other hardware (you’re not going to set aside one of your USB ports for exclusive use by the guest OS, just in case it needs it, and certainly aren’t going to require users to plug in a second keyboard and mouse or even a separate graphics card for use by the guest OS)

So, the two have to cooperate. I think http://cs.yale.edu/homes/aspnes/pinewiki/Virtualization.html lays out the options well.

The ideal goal to run any guest OS, unmodified, isn’t attainable, as it would require the host OS to, somehow, know how every possible guest OS, including ones yet to be written, accesses its hardware. So, you either support specific OSes (say only Mac OS), or set rules that guest OSes must follow to be supported.

Edit: the latter is what typically is done, and isn’t that bad, nowadays, as most OSes are made to run on PC hardware, where device discovery, etc. is standardized.