The problem described in the linked bug is that the app is reacting to mouse events sent while the pointer is moving over it when it does not have the keyboard focus. However, in general, this is acceptable behavior for both Wayland and win32: keyboard focus is not a requirement to receive mouse events. It's up to the application to react (or not) to such mouse events, a decision that may or may not take into account the current keyboard focus.
My guess is that the fundamental problem at play in this particular case is that since winewayland does not clear the win32 focus state when a surface loses the Wayland keyboard focus, the game thinks it's still focused and acts accordingly (instead of, e.g., having dropped the confinement and shown the cursor when focus was lost).
I don't know of any good-for-all-cases answer to the more general question about what to do when the lock is disabled by the system itself, since AFAIK this is not a possible scenario under win32. All of the following are viable options depending on the application:
1. Do nothing (current code, i.e., keep relative motion enabled) 2. Block all pointer motion events (this MR, but what about mouse button/axis events?) 3. Switch to absolute events (e.g., if we are not dealing with a mouselook scenario)
One concern I have with option (2) is that the cursor will just disappear when entering the unfocused window and leave the user without any feedback about what's going on.
My personal preference is maintaining the current, more unopinionated "do nothing" approach and try to make some progress fixing the real underlying issue that's causing the bug.