The idea of "on-demand" messages generation suggested above would imply generating this message in get_message handling (in the wineserver). Trying to see if that is about how it works on Windows, I made a test making PeekMessage() loop in test's MsgCheckProc in WM_WINDOWPOSCHANGED. And this yielded no change: PeekMessage wasn't returning anything and the test was still succeeding (i. e., receiving mouse messages as expected after WM_WINDOWSPOSCHANGED and winevent notifications). However, playing more with it, I discovered that adding a delay before that message loop (implicit with trace() or, better for reliability, Sleep(50)) resulted in WM_MOUSEMOVE being delivered in this message loop (without otherwise preceding WM_SETCURSOR however). I think these results basically exclude the possibility that Windows generates that message "on demand" during PeekMessage handling, hard to guess how the delay there would be possible (without anything else besides trace or Sleep() being called)
. I think more likely Windows hardware events handling process sees the window configuration change with a bit of delay and generates the event.
It seems to me that the behavior would be the same if it simply invalidated the previous cursor pos (with the same delay), and then generated the event on-demand.
We do it a bit differently in Wine, but I don't see why a hardware mouse move couldn't be queued at the time the window is moved, without requiring a separate server call.