I think this then depends on whether events have been received already or not, and that's maybe not very deterministic?
It's pretty stable. The game changes the size of its main window after the NtUserSetActiveWindow() call.
It is rather a regression from d56f36c1 as I believe the NtSetForegroundWindow call above can only be made by the current foreground window, to give foreground to a different window, so it won't trigger extra requests. The requests are caused by the now restored `NtUserSetActiveWindow( hwnd );` call.
In this case, the requests are indeed from the NtUserSetActiveWindow() call. However, I think it's also possible that an application might respond to the WM_ACTIVATEAPP/WM_ACTIVATE message from NtSetForegroundWindow() and call things like SetWindowPos().
maybe unconditionally skipping the SC_RESTORE message if we called NtUserSetActiveWindow, and wait until we get another state update message is better?
I am not sure. Could it be possible that there is no more WM_WINE_WINDOW_STATE_CHANGED message. Maybe we can just post another WM_WINE_WINDOW_STATE_CHANGED. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10725#note_137438