I hope I deduced all the important rules how startup info affect ShowWindow behaviour. To summarize test results and implementation:
1. STARTF_USESHOWWINDOW in startup info affects the first ShowWindow (explicitly called or implicit from creating window with WS_VISIBLE) for eligible windows. Eligible windows are those which are not child windows. Popup windows (owned or not) are eligible if and only if they have WS_CAPTION (which is WS_BORDER | WS_DLGFRAME). Whenever eligible window is shown, the first ShowWindow use is counted (even if the actual ShowWindow command wasn't overridden due to rule 2). SetWindowPos(SWP_SHOWWINDOW) doesn't count as showing window, it neither consumes the 'firstness' of showing window nor the result is affected by startup info. Message windows are eligible.
2. For explicit ShowWindow call, eligible as per p. 1., the actual show command is only overridden if it is SW_SHOW, SW_NORMAL or SW_SHOWDEFAULT. The other show commands count as first ShowWindow use but are not altered.
3. STARTUPINFO docs suggest that Windows GUI application might have some different behaviour. I failed detect such (tried with both my separate ad-hoc test app linked as Windows GUI, as well as user32_test.exe, both 64 and 32 bit).
4. While SW_SHOWDEFAULT is supposed to use wShowWindow from startup info (as per both ShowWindow and STARTUPINFO structure MS docs), I failed to find any way to trigger that behaviour. For me once ShowWindow call is not the first (in the sense of p. 1) SW_SHOWDEFAULT is never overridden by startup info. I tried Windows GUI executable and even setting compatibility mode down to Win95 on Windows 11, the included tests still succeed.
The remaining todo is orthogonal to the issue and patch and is related to SW_FORCEMINIMIZE current handling.