QQuickWindowPrivate::lastMousePosition and QGuiApplicationPrivate::lastCursorPosition can be out of sync.
https://codereview.qt-project.org/#/c/142532/ doesn't assume that the mouse cursor moves when you touch the screen somewhere else. On eglfs platform, the mouse and touchscreen are completely independent, so you can have one MouseArea hovered by the mouse cursor, and another hovered by the touchpoint while a finger is pressed. On X11 though, the cursor probably moves when you touch the touchscreen. The X server is doing that (I think?), which means Qt will receive a mouse move event, and that will update QGuiApplicationPrivate::lastCursorPosition.
https://codereview.qt-project.org/#/c/127724/ however uses QQuickWindowPrivate::lastMousePosition to send a hover event once per frame. If a touchpoint was used to synthesize a mouse event, then lastMousePosition will be the position of that touchpoint, which may or may not be the same as the actual cursor position.
So the result is that tst_TouchMouse::hoverEnabled fails when flushFrameSynchronousEvents() occurs, because the test does not simulate the extra mouse move that would occur on a real X11 desktop system (nor should it, because it was designed with embedded linux in mind). Sometimes the test runs fast enough that flushFrameSynchronousEvents does not occur, and then it passes.
In general, for the future, we need to assume that it's normal for multiple MouseAreas to be hovered by different devices at the same time. Qt 6 ought to have complete multi-device support because that's the future on Wayland etc; and we can try to get there in the mean time. QGuiApplicationPrivate::lastCursorPosition is the position of the core pointer (actual mouse cursor, assuming there's only one), but maybe QQuickWindowPrivate::lastMousePosition should be put into the QQuickPointerDevice instead? Maybe flushFrameSynchronousEvents should then send hover events for each device? But that may break assumptions elsewhere... has to be done carefully, and 5.8 is too soon now.