Repro steps:
I did some superficial digging into the source code try to localize the cause. This was one thing that stood out:
https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/src/gui/sdlmain.cpp#l1596
Clearly a battleground with multiple attempted bandaid fixes. Not sure if this most recent incarnation I'm seeing is a regression or not.
The first time that surprised me is that if you were using Win32 WM_KEY/WM_SYSKEY events, you shouldn't be getting alt-tab key events at all. Normally you only get a WM_SYSKEYDOWN for the initial alt, and then nothing else for either the following tab key, or any of the keys for the alt-tab sequence as you return focus to the application window. So, I looked into SDL 1's behavior here. It looks like it has two separate keyboard input paths, for its windib and dx5 backends. The former uses Win32 WM events for keyboard input. To check my hunch, I forced this path to be taken by setting output=surface and setting the environment variable SDL_VIDEODRIVER=windib. And indeed, when I do this, the issue no longer occurs. So it only occurs on SDL's dx5/DirectInput path. I'm guessing you folks already know that, but I thought I'd include it just in case.
Could be a possible DirectInput regression in Windows 10, but odds of that seem low.
SDL 2 dropped DirectInput for keyboard input, and in general I don't know of anyone using DirectInput for keyboard input anymore.
I did some testing today and do see this with 0.74 which uses SDL 1.2.13.
My builds here: https://www.vogons.org/viewtopic.php?f=31&t=55706#p609435 that use SDL 1.2 current branch do not have the issue.
Can someone else verify?
https://hg.libsdl.org/SDL/rev/090d764c56e4
Last edit: DosFreak 2018-05-10