In handlers, grabPermissions provides finer-grained control over grab transitions, turning it into more of a negotiation. In QQuickItem we have setKeepMouseGrab and setKeepTouchGrab, which are similar to not having any of the Approves flags on grabPermissions (i.e. ApprovesTakeOverByItems, ApprovesTakeOverByHandlersOfDifferentType etc. are not set to true). Also, why are mouse and touch different? Any QEventPoint can have its exclusive grabber set, and if the item wants to keep the grab, that's probably independent of which device is being used. I think we had keepMouseGrab first and added keepTouchGrab just for completeness, but that's not the last event type that can be grabbed.

If we add the ReactsToGrabbedPoints flag, that's probably going to be relevant to item subclasses too.

A few years ago I was thinking that handling pointer events in item subclasses ought to become obsolete, so none of this legacy stuff matters: composition is the way forward. Event handling is a facet, not part of the definition of any item. Items are visual, and event handling should be added on by adding handler instances. But it doesn't seem realistic, because of the "classic OO" instincts of C++ programmers: they always want to subclass and override virtual functions to change behavior.