NtUserSetCursorPos will ask the driver to change the cursor position too, and so if the user is currently moving the mouse and GetCursorPos retrieve a slightly outdated position when win32u loads, I'm afraid that this could possibly cause some stutter?
Then `winex11` guards against such scenario as it only allows cursor to be moved when it is also grabbed, but I don't think it's the case in other drivers.
I'm also not completely sure to understand why this is an initialization issue only. We currently only receive mouse input when the mouse moves over a Wine window (or when it's been grabbed but let's ignore that case). So, whenever the user is doing something else, we don't receive any mouse input and `GetCursorPos` can very well diverge.
If that causes some issues, for some reason, I'd think that we should maybe instead drop the `GetCursorPos` driver callback altogether and its cache mechanism, which is obviously bogus. This means that applications won't be able to get the true cursor position when it's outside of a Wine application but that would make everything more consistent from the Win32 point of view.