And trying to run the Windows 3.1 setup.exe under MS-DOS 6.22 running a CD-ROM driver (OAKCDROM) and EMM386 loaded, I see the CPU get into the hang condition trying to #GP(0) fault for a IN AL,DX instruction. Though this should have worked properly.
Edit: Managed to fix the issue.

Windows 3.x's EMM386 somehow doesn't detect all RAM? It only shows 256KB of EMS memory available, unlike MS-DOS EMM386's 50ish MB (all HIMEM extended memory).
Edit: Checked Windows 3.1 EMM386.SYS without parameters. It only reports 256K (262144 bytes) of EMS memory? That's of 640K EMS memory total, as reported by the driver to MEM.EXE.
So there's definitely going something wrong with it's execution.

I do notice something interesting with Windows 3.1.
Running it in Standard mode, even with EMM386 loaded, runs fine. I can run apps fine.
But when in calc.exe I try to perform any of the buttons, it gives a beep and does nothing (except give a beep).
Only the C (clear) button works, which causes the text "Invalid value for this" to flash a few times before resetting to 0.
Opening the app also gives said value inside the current output box. Using the Edit and View menu items gives a beep also, doing nothing.
So does 'Search for help on...'. The other help menu items function as they should (opening the help, which seems fully functional).

Just found an issue with the segment write function detecting if it's active or not. It increments a variable to indicate it's active and is supposed to decrease it when it terminates (keeping track of if it's recursively called or not executing for internal state reset purposes). When it was executing a stack access that was pending or faulting, it would mistakenly increase the counter before returning to the calling function (the opcode handler) instead of properly decreasing the counter.
So that would cause future segment (and descriptor) handling to correctly increase it, where the level of the handler was always 1 (or for multiple calls) even higher. A bit like Windows' IRQL getting stuck on a higher level instead of properly decreasing, with some calls increasing the level even further (which isn't supposed to happen).
So in that case, even handling that isn't using said function is behaving as if it's called by the recursive handler, resetting instruction state (changed registers, changed descriptor caches etc.) upon being handled, instead of handling it like a non-resetting instruction (or task switch-specific behaviour failing becauseo of this, as it runs some things without said resetting behaviour (which is required for it to function properly)).