This helps VPet-Simulator game which currently may voluntary move its window while mouse is pressed.
The issue comes not from the game itself but from .Net WPF (native, not related to Wine-Mono). WPF may generate move events for its Grid class during some internal mouse position sync. The information on the mouse position comes from the last relative mouse coordinates reveived from WINAPI mouse event. When the window is moved with SetWindowPos() without actual mouse movement those are not updated and WPF ends up with wrong mouse coordinates (as relative mouse coordinates are wrong after window move).
I separately tested that WM_MOUSEMOVE is delievered to the window receving mouse input even if another window from the same thread was moved.
Thinking of it, sending WM_MOUSEMOVE after window position change makes sense. WM_MOUSE... messages have relative coordinates and if an application tracks the mouse position solely based on that (which is probably a valid behaviour) WM_MOUSEMOVE with new relative coordinates is necessary to keep it consitent.