Take into account that we will likely need access to `wayland_surface` from within many of the pointer handlers anyway
What will we need it for exactly?
In fact, I wrote a win32 program that ends up recycling a HWND value in less than 2 seconds under Wine, so I wouldn't want to rely on HWNDs being unique. In practice it would require either a misbehaving or malicious program and unfortunate timings to get into such a state in a way that affects the driver, but this doesn't really alleviate my concerns.
My impression is that you're trying to make it unnecessarily robust. Of course, correctness is important, but I don't think we really care about malicious or misbehaving programs in general. I may be wrong but my gut feeling with mouse input is that it is updated often enough for such transitional state issues to not really be a problem in practice.
If a window is destroyed / created, you will get a lot of different and concurrent mouse events anyway, and I'm pretty sure there's plenty of other places in the input stack where the target window validity is checked already, or where stale hwnd values are used.
The high complexity concern stands even if we decide to not care about (5) and just go for the rest (see for example the code in `pointer_handle_enter` in the `wayland-part-6-no-double-lock` branch).
What about keeping a single "last used" surface for the cursor and use it on enter event, until SetCursor is eventually called if it needs to be updated? You also wouldn't need the current surface for that.
--
Also, this is only some suggestions to make things simpler. If you think it's better to be more robust here and you prefer to keep the locks, I can probably live with it.