Clarifying `zwp_locked_pointer_v1` unlock warping behavior with `set_cursor_position_hint`

Hi,

I'm looking to get a bit of clarification on the behavior of warping during zwp_locked_pointer_v1 unlock.

The spec says:

  When unlocking, the compositor may warp the cursor position to the set
  cursor position hint. If it does, it will not result in any relative
  motion events emitted via wp_relative_pointer.

Sway implements this behavior by sending a wl_pointer.motion event, but no wp_relative_pointer.motion event when warping to the position set via the position hint. As far as I could tell, this follows the spec. Whenever wl_pointer.motion should be inhibited, the spec is explicit in saying so.

However, it appears that implementing this behavior has broken some clients (ref). Since the client is sent a motion event on unlock warp, it interprets it as user input and does something unexpected (in the linked case, it swivels the camera).

It seems to me that the "spirit" of not sending relative motion events on unlock is to prevent this sort of behavior. In that case, should the regular motion event also be inhibited on unlocking, so long as a cursor hint is set? (Presumably, if it is set, the application is already keeping track of its own cursor.) Otherwise, it seems like an application would have to track state in order to drop the first motion event after unlocking, which seems unwieldy.