The central part here is that mouse messages from pointer updates are not generated unconditionally, that depends on whether the app is calling DefWindowProc for them. Also, as mentioned in [1], "If an application selectively consumes some pointer input and passes the rest to DefWindowProc, the resulting behavior is undefined.".
While the logic covered by tests, specifically, the "duality" of mouse messages generation, whether it is done during DefWindowProc or independently, may like a convoluted implementation detail, I think it is actually not and follows strict functional logic (well, as soon as design decision is not have an implicit call to say whether mouse emulation from pointer is needed or not but instead that is based on whether DefWindowProc is called).
I think the specifics covered by test and implementation deduces from the following:
- if the application processes pointer messages and doesn't call DefWindowProc at all for them (or, well, doesn't call it for WM_POINTERDOWN which starts emulation action), pointer doesn't influence mouse anyhow; - when WM_POINTERDOWN is called, WM_LBUTTONDOWN (or any mouse message) can't be immediately issued because depending on the details on touch (e. g., long touch) the mouse message may be also _RBUTTONDOWN or DBLCKICK (while we do not support it yet). So any mouse message is generated as soon as WM_POINTERUPDATE is received which changes pointer position. If no such WM_POINTERUPDATE is received until WM_POINTERUP the mouse message sequence is generated at that moment; - Mouse messages are interconnected with current cursor position. So as soon as WM_POINTERUPDATE triggered button click, and mouse pointer is being held, the difference with cursor position and WM_POINTERUPDATE should result in cursor position update and WM_MOUSEMOVE. So once pointer-to-mouse tracking is started it is not possible to do as the reaction on DefWindowProc calls anymore, that should reflect the independent differences to cursor position (e. g., from real mouse movements or explicit SetCursorPos, like in the tests).
Patch "server: Merge WM_POINTERUPDATE messages." is not strictly related, but I think constant generation of WM_POINTERUPDATE when the app doesn't consume those is also a problem. On Windows WM_POINTERUPDATE is likely "on-demand" generated similar to WM_MOUSEMOVE. Indeed, WM_POINTERUPDATE are received periodically as soon as the application peeks messages constantly. But if it doesn't then on Windows the app won't be left with the huge queue of identical WM_POINTERUPDATE messages.
1. https://learn.microsoft.com/en-us/windows/win32/inputmsg/wm-pointerdown