No, I believe my description is correct.
I didn't imply otherwise. I was just pointing at another potential issue. as the current cmd code sets the Std handles with the potentially redirected streams, it doesn't look right that we reuse the O_TEXT bit that could have been set by cmd's father. I'll dig a bit more into it.
Another thing now seems suspicious to me with the second patch: I realized msvcrt.spawn does not set std handles in STARTUPINFO, and with that change in the second patch now nothing on the spawn path is going to set the system's std handles
the way msvcrt calls CreateProcess (no console flags, inherit handles = true) will automatically inherit parent's std handles (except if child process is in GUI subsystem, and it's a console handle); so they will be set to parent's std handles so if no one temper the std handles directly, the fd=0,1,2 should be in sync with the std values (both in parent and child) on the other hand, if someone changes std handles without updating fd 0,1,2 entries' osf handles in msvcrt, I don't know what would happen (and createprocess tests show there are a variety of subcases depending on CreateProcess flags, nature of handles, CUI/GUI child...) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11710#note_149406