The known regression happens in the The Elder Scrolls IV: Oblivion and Fallout: New Vegas launchers. The buttons in the launchers are not clickable.
What happens there (I only debugged The Elder Scrolls IV: Oblivion) is that the launcher, upon receiving WM_MOUSEMOVE, sends STM_SETIMAGE message (from its code and not through some other API; that happens after returning from window proc for WM_MOUSEMOVE). Handling of STM_SETIMAGE in user32/static involves calling SetWindowPos() (without actual size change in this case), so this results in auto-inducing loop.
FWIW v6 of the original patch in https://gitlab.winehq.org/wine/wine/-/merge_requests/6708 actually had the check I am adding here, but it was considered not needed on the basis that WM_MOUSEMOVE can happen anytime regardless.
This specific manifestation is in theory might be possible to fix in static control implementation, but it doesn't look right: the test shows that Windows doesn't send mousemove if position is unchanged and it looks important to fix it on the lower level; some apps in principle may react on that in a similar way themselves without our controls involved.