Support for wayland client surfaces embedded in QML Flickable element

That bug happens in the following use case:
A Qt Wayland compositor has a QML "Flickable" element which contains several QWaylandSurfaceItem as children.
The user presses the mouse button with the cursor on one of the wayland surfaces and swipes right for example. The user releases the mouse button. The user clicks on another wayland surface.

Unexpected behavior:
The first client application does not get notified about the fact that the user released the button. The second click on the second surface is wrongly sent to the first application.

My findings :
QtWayland correctly sends a "wl_pointer:button" to the first surface's application. When the flickable element detects that the user is actually performing a "swipe" move, the Qt Wayland component gets notified and sends a "wl_touch::cancel" event to the application owning the first surface, but it does not send any event related to the "wl_pointer" input device, which causes the application to remain unaware of the fact that the button was released by the user. Additionally, QtWayland server-side Pointer's internal focus is stuck on the first surface, since it considers that the user did not release the button.
AFAIK, Wayland does not define an equivalent of "wl_touch:cancel" for the "wl_pointer" kind of devices, so the problem can not be solved in a straight-forward way.

Idea:
An extension of the Wayland protocol could be used to work around that issue until Wayland defines a standard "wl_pointer:cancel" event,