I tested this on the 2011 in 286 mode, and that works as expected. Will test on the 2121 in 386 next.

Got the same issue on UniPCemu in Standard mode. The info about exit to return to Windows is printed, then 50% or less of key input is discarded somehow(even same keys being pressed after each other). Maybe an issue with config? I have "switches=/k" in config.sys' common section. Might that be a cause?

I can't say much about this problem until I've fixed #34 and #35, which I think could be related (especially #34).
But this is a 386 mode problem for me, so your situation could be much different.

Now that I think about it, the fact that the keyboard is not responding could be due to a corruption of the IDT by a buggy memory operation. I would set a mem trap on the IDT segment (or real mode IVT) to see what happens at Windows exit.

But since part of the input comes through, some keys DO end up at the MS-DOS prompt(UniPCemu running 80386 executing Windows 3.1 in Standard mode). It looks like there's some odd kind of delay of sorts between the key input and the MS-DOS buffer? The keys don't end up in the MS-DOS buffer until at least five to ten/twenty keys have been pressed after it. Like there's some kind of input-timed(not RTC/PIT-timed) lag between the reading of the input buffer? Maybe an issue to do with the 8042? The input clock comes to mind(not emulated at all atm, except basic timings for receiving input)? (Windows 3.1 still returns to text mode without any text on the screen when running in 386-Enhanced mode in UniPCemu)