Well, you would need to install 20 copies of OSX if you have 20 apps installed, for one.
Also, for a regular app process, standard unix-level memory protection plus sandboxing should be enough. Regular apps have no use for the virtual ring0 privileges available in a "bare-metal" environment that such virtualization emulates.
Sure, that's like novm (https://github.com/google/novm). But you're still running 20 kernels. A picoprocess architecture is better, but I'd still go with containers.
But, you'd need a complete implementation of the OSX kernel and library API surface, because that's what an OSX app expects. If you're going to try to re-use the host kernel via a virtualCPU backdoor, you're not really virtualizing anything anymore and could just stick with the unix process model?
Not exactly, because using a separate CPU with a shared kernel can very effectively isolate processes from each other which is not possible with the unix process model. It would take either a serious kernel bug or a bug in the CPU hardware/microcode to cross the barrier in case of an exploit e.g. in a browser.
I'd rather see the sandbox model for process isolation improved, instead of trying to re-invent it from scratch with a virtual CPU that has backdoor traps for calling into the original kernel for almost everything. I'd think the attack surface would be about the same for that, and any kind of virtualization that is so lightweight that it reuses most of the host kernel. That's exactly the problem that the x86/x86_64 memory protection and CPU ring levels were intended to solve! :) Plus you won't have the stress of having to virtualize a separate network card, file system and memory map.
Also, for a regular app process, standard unix-level memory protection plus sandboxing should be enough. Regular apps have no use for the virtual ring0 privileges available in a "bare-metal" environment that such virtualization emulates.