Here is a dead simple AutoHotKey script to fix the problem. The trick in preventing this issue is to always release the number key before releasing the windows key. This script handles that case, and emulates pressing them in the right order.
; Register Win + 0-9 with our custom handler to add key delay.
LWin & 1::WinNumber(1)
LWin & 2::WinNumber(2)
LWin & 3::WinNumber(3)
LWin & 4::WinNumber(4)
LWin & 5::WinNumber(5)
LWin & 6::WinNumber(6)
LWin & 7::WinNumber(7)
LWin & 8::WinNumber(8)
LWin & 9::WinNumber(9)
LWin & 0::WinNumber(0)
; Custom handler
WinNumber(numberKey) {
; Wait until the user has released the number key. This allows us to emulate
; standard windows behavior of "cycling" through the multiple open windows
; in taskbar position of the number key.
KeyWait, %numberKey%
; If the Win key is still pressed, windows will not bug out and create
; the grey box window. Just press the number key here to select the window
; from the taskbar.
if GetKeyState("LWin", "P")
Send, {Blind}%numberKey%
; If the user has already released the windows key before releasing the
; number key, press the windows key back down along with the number key.
else
{
; Manually press down on the Win key without releasing, then press the
; number key.
Send, {Blind}{LWin down}%numberKey%
; Wait 1/10th of a second before releasing the windows key.
; This is what prevents the bugged window from popping up. Without a
; delay, the bugged window occurs. I tested a delay of 50 ms instead
; of 100 here, but the bug still ocurred. 100 is reliable.
Sleep, 100
Send, {Blind}{LWin up}
}
return
}