TapHandler in parent of an event-handling Item always declines the press event

Item {
    TapHandler { }
    Button { }
}

The button grabs on press, and QQuickSinglePointHandler::wantsPointerEvent() refuses to "choose" a point that already has an exclusive grabber:

        for (int i = 0; i < c && !chosen; ++i) {
            QQuickEventPoint *p = event->point(i);
qDebug() << "deciding about" << p << "grabbed?" << p->exclusiveGrabber() << "want?" << wantsEventPoint(p);
            if (!p->exclusiveGrabber() && wantsEventPoint(p)) {
                if (!chosen)
                    chosen = p;
                ++candidatePointCount;
            }
        }

That's correct in some cases but maybe should be configurable somehow. If you want to modify behavior of a whole UI by stacking up (a) handler(s) somewhere, your choices are to put them above, below or inside the controls you want to modify. QTBUG-64491 was mostly about putting them inside; and that works to an extent, but you might not have access to the inside of some control inside some other component. If you place an Item at a high Z above the component, the handlers there get events of course, but they accept events; and after that, QQuickWindowPrivate::deliverPressOrReleaseEvent() goes into handlersOnly mode, so items under the high-Z "glass pane" don't see them. (Another idea was to make each handler configurable whether to accept events or not.) If you put handlers into a low-Z item, or into the parent item that contains the component, a SinglePointHandler gets to see the event because QQWP is in handlers-only mode and keeps delivering to handlers below the item that accepted the event; but TapHandler ends up refusing the event, and that's what this bug is about. DragHandler on the other hand will passively grab, because it wants to be able to take over the exclusive grab later if you start dragging. So the fact that TapHandler is not configurable to behave that way is inconsistent.

Making TapHandler a multi-point handler might have the side effect of fixing this too.

Ran into this while trying to figure out how to add a press-delay feature to FakeFlickable: I wanted to use TapHandler's long press detection. But there doesn't seem to be a good place to put a TapHandler to get that behavior.