"Windows 386 v2.0..x itself was still a 16-bit real mode program, even running on the 386 VMM."
VMM is virtual machine mode, which allowed a computer running Windows, to run multiple 8086 real mode applications simultaneously. so.... Windows v2 running in 16-bit real mode could run multiple VMMs, but could not run itself. ( It actually would complain that it could not run itself... ) Quardecks DeskView could run AutoCAD in one window, and Windows another window, and could run two copies of AutoCAD, but not two copies of Windows v2.
8086 real mode is limited to >1Mb of memory, using segmented ( unprotected memory ) memory addresses, or up to 15Mb more of data memory using the LIM 4.2 spec memory boards and appropriate software. Command.com could run in multiple windows, but could easily crash the Windows program.
80286 real mode is limited to >16Mb of memory, using 16-bit unsegmented addresses, however requiring a processor reset to move between 16-bit mode and 8086 real mode. Command.com could run in multiple windows, but it was not command.com that could crash the program, the program ( Windows 2.0 ) could easily crash itself.
80386 real mode again limited to >16MB of memory, could use 32-bit addresses, did not need to reset the processor to move from 16-bit mode to 8086 segmented mode, and included a VMM, Virtual Machine Mode capable of running 8086 processors in a protected memory space. Command.com could run in multiple windows, but with the 3.1 update, could only crash its own task, and not effect other programs. ( Windows 3.x had a generous helping of GPFs ( General Program Faults ) from poor drivers, which need constant attention.. )
But out of all of this, Windows 2.0 should have been able to run a copy of itself under VMM, ( unsegmented memory hypervisor, running a segmented memory application ), but the program itself would not allow it to operate in this fashion.