I'm not completely sure if passing the message to wineserver like that is intentional of it it's only there for historical reasons, as far as I understand the message is always used and always the same.
My intention here is to use wineserver instead of the desktop process to track the clipping thread, and move more of the asynchronous cursor clipping mechanism to wineserver:
* to trigger actual cursor grabs (replacing the WM_X11DRV_CLIP_CURSOR_REQUEST message),
* to trigger cursor releases (replacing the WM_X11DRV_CLIP_CURSOR_NOTIFY mechanism),
* and ultimately moving fullscreen window clipping optional support entirely to win32u (also replacing WM_X11DRV_CLIP_CURSOR_REQUEST).
This will ultimately help getting entirely rid of the winex11 clip_hwnd window, which causes some performance hit when ClipCursor is often called with alternating rectangles (as the window gets re-created).
Later, I think that these messages would be sent to a dedicated input thread, whenever it gets introduced, to also avoid relying on application threads checking their messages, and to avoid tainting some application thread queue with internal message bits.
In the same way, using the input thread, cursor updates could be posted to it, instead of regularly calling sync_window_cursor and removing the need of a clip_hwnd entirely.
---------
Alternatively sending the messages could perhaps be done outside of wineserver, but I think there's still a need for it when thread input are destroyed, although maybe resetting the cursor clip rectangle in SetForegroundWindow / SetActiveWindow could be enough.