DragHandler.centroid.pressPosition glitches if window origin moves on Win10 touchscreen

Context: I was trying to implement a grabbable handle by which an entire frameless window can be grabbed and moved. This seemed like it should be straightforward, basically just:

DragHandler {
    id: windowDragHandler
    target: null
    onTranslationChanged: {
        // move the window by the specified transalation
        // as this moves the origin of the "scene" coordinate system, it restores translation == 0,0
        // (mouse is over the same point in the scene it was originally)

        Window.window.x +=translation.x
        Window.window.y += translation.y
    }
}

And in fact this works fine with a mouse.

However, when dragging with a finger on my Windows 10 touch device (surface pro 3), it glitches wildly.

What seems to be happening is that, the window moves, the windowDragHandler,centroid.pressPosition switches back to the scene position of the last mouse press, rather than the touch start position, even though the finger is still touching the screen. centroid.position does not similarly revert, and is still under the touch (though its scenePosition of course changes to account for moved the window origin).

windowDragHandler.translation also glitches, but this seems to be merely because it's being computed as centroid.position - centroid.pressPosition and pressPosition is incorrect.

centroid.id also changes back to this long-ago-released mouse click (in my experience, it's always id=0x1000000, and the finger touch is always 0x2000001, though I don't know where these ids come from.

As soon as the finger moves at all, pressPosition and id go back to the touch (so translation is correct again), but it breaks the next time the window moves.

I've made a small example app that will show the various behaviors and property values.
It shows a yellow circle where the hover point is shown (not relevant to this bug), a blue circle at the pressPosition, and a red circle at the position, and a black line originating at the pressPosition for the translation. If you hit space, it translates the window by the drag translation.

To reproduce the bug, click anywhere (e.g. lower right), then touch somewhere else (e.g. upper left) and drag a short distance with a finger (e.g. to the middle). Then, while still holding the touch, hit space. (which moves the window by the translation, which should bring the blue circle back under the red one). However, note that the blue circle has instead now jumped to the scene position wherever the last mouse click was (rather than the touch press, or the global position of that mouse press), and the translation is now a long line from that back to the touch position (mixing the mouse and finger information). As soon as the finger moves at all, things jump back to normal.

Probably unrelated and and I have not investigated enough to know if it is another bug or just something I need to configure, but just in case it's somehow relevant:
This example app has one other quirk, in that does not seem to react to the surface pen at all, except intermittently the hover position will update. This seems to happen only when entering or exiting the window, or when moving the pen out of the digitizer's range. But the HoverHandler does not update as the pen's hover indicator moves around.