A V86 hypervisor is relatively simpler, and a lot of DOS utilities in the late 80s throughout the 90s took advantage of V86 mode, like the (in)famous EMM386 and debuggers like 386SWAT and CUP386. It is a little-known (or perhaps known but little-appreciated) fact that Windows 3.x Enhanced Mode and Win9x are actually architecturally based on a V86 hypervisor and "library OS" concept, instead of a traditional OS like the various Unices, Linux, and the NT line. They also perform "hyperjacking" of the DOS environment at boot time.
The article also suggests that the idea was in summary a bit more akin to VT-x than to vm86, but saving things in the TSS instead of a new VMCS. A fully straightforward extension of vm86 to "vm386" wouldn't work, because vm86 mostly got away with its simplicity due to the fact that 16bit x86 did not know about segment descriptors, TSSs, and all that jazz.
And in the end, long mode finally got rid of most of the segmentation, "hardware" tasks including TSSs, and other cruft in x86 that had long been abandoned (the latter at least already being regarded as a bad idea during the design of the 386). So it's probably a good thing that some "vm386" mode didn't require keeping more of that around.
I agree that is was good the designers of the 386 got rid of some cruft in designing 386 protected mode. It's unfortunate they didn't lean harder into BIOS calls to hide implementation details (such as allowing only the BIOS to manipulate page tables, and enforcing this by having the BIOS be the only ring0 component), effectively making the BIOS a hypervisor that only supported one guest kernel at a time. This is what the DEC Alpha did with its PALCode, and would have given a smaller interface that needed to be maintained in the future.
It would have made writing a BIOS more complicated, but would have made future kernel and hardware work more simple. It would also have meant all 32-bit and 64-bit kernels would have been paravirtualized from day 1, greatly reducing the need for hardware emulation in multi-guest hypervisors.
Of course, hindsight is 20/20, and it a business risk to depend so much on BIOS implementors unless you provide them a robust liberally licensed reference implementation to tailor to their hardware.
Yeah, it sounds like KMag essentially wanted the BIOS to be a sort of microkernel, with other kernels being implemented under it. Beyond performance concerns, given the PC's history I'm also not sure whether e.g. Linux developers (which initially was, well, Linus) would have been happy with whatever microkernel and API had been given there.
I do wish Intel had simply extended V86 mode to a "V386" mode, as this interesting discussion suggests, instead of adding completely new and different instructions and data structures: http://www.os2museum.com/wp/an-old-idea-x86-hardware-virtual...
all while containing the ability to run on every recent version of 64-bit Windows
The presence of that one little extra word "on" changes everything...