And I honestly never understood this apart from Microsoft wanting to finally kill Win16: after all, it’s not like V86 mode (whose absence in x86-64 is the official justification) is actually required—non-x86 versions of NT had perfectly serviceable Win16 support through the extremely expected approach of having a full PC emulator inside[1]. (Some even extremely briefly had x86 Win32 support[2], but that wasn’t resurrected for Windows for ARM either, perhaps because the sheer amount of stuff in the system has grown so much since that time.)
Mind you, the decision was made with the release of (I think) Windows XP for x86-64, in 2005. I actually briefly used a computer with Windows 3.11 on it around that time (oh the wonders of school IT). I’m not saying Microsoft’s decision was wrong, though, only that the official rationale is kind of bullshit.
... I’m trying to imagine how one’d handle interrupts in this setup, and it sounds kind of terrifying. Reprogram the LAPIC each time? Carefully code the interrupt entry to work as both 32- and 64-bit code to determine if it needs to switch back? Ouch.
You don't need to use the same IDT as in long mode. Just have a 32-bit one that decides whether to handle an interrupt (e.g. vm86 traps/emulation) or re-enable long mode and forward it to the 64-bit handler.
But you don't have to imagine -- early amd64 Linux could do it, and there was a patch floating around that kept that feature all the way to 2.6.2x series.
[1] http://bytepointer.com/resources/old_new_thing/20060525_178_...
[2] http://retro.ircx.net.pl/nt/mips/wx86/