I'm betting those guest instances are Windows 3.1 Real Mode however and so cannot load most protected mode drivers. IIRC, there are a bunch of protected mode things like the VDM that take control over the system because there's no such thing as nested virtualization until about 2005-2006 when VMware and similar hypervisors pushed for it.
The guest instances are fully 386 Enhanced Mode instances of Windows 3.1. Windows 3.1 (and Windows/386 and Windows 3.0) is implemented as an 80386 DPMI server, much like the DOS4GW you used to play Doom, and the the actual GUI code is a DPMI client. Windows 95 is also a DPMI server.
Windows 3.x could also run in “standard mode”, where it used a 16-bit only DPMI server. The Windows GUI system could run in real mode or as a DPMI client.
As far as “nested virtualisation”… Windows 3.1’s DOS windows could actually in turn run more instances of Windows 3.1, because Windows/386 relied on virtual 8086 mode only and Windows 3.x used DPMI which can be nested.
The protected mode drivers are already loaded in this scenario. The VMM and all of the VxDs are already up and running. All that's really happening here is the first VM (the "systemm VM") is running the DOS+Windows 95 kernel/user/gdi/system/network/display/keyboard and applications, and a second VM is running the DOS+Windows 3.1 kernel/user/gdi/system/network/display/keyboard and applications.
The former's VMM and VxDs were largely a superset of the latter's. The only real trick is that there was a secret handshake between the DOS program WIN and the Windows KRNL386 program that has to be satisfied by whatever tries to start it in that second VM, otherwise KRNL386 just exits immediately. One cannot use WIN to start KRNL386 in the second VM. WIN does too much other than running KRNL386. It has to be something else that does the secret handshake and only tries to run KRNL386.
The screenshot explicitly shows "386 Enhanced Mode" in the Windows 3.1 about dialog.