Well the start address is mostly a detail, we could very well put some ntdll address there if necessary. The necessity to keep that thread absolutely hidden on startup is more of an issue. I know it's not happening on Windows but how confident are we that it needs so be like that? At what point is it okay to spawn a thread?
Well, I don't believe that some work arounds on this level can work well. It would take some indefinite effort finding out an DRM in the wild as an example which will break this way, but even if we can't find it IMO the right question here is what will we do if we find one (while I did see a few games which do check those threads, previously they were breaking when we had start addresses in old dll.so which were not properly traceable). IMO we better have that right than hope that nothing needs it.
That thread needs to be able to communicate with other application threads, especially it needs to be able to send window messages, otherwise it becomes a bit pointless to have and cannot replace Wayland thread, or be used to simplify macOS driver much either. We could maybe use only Wine internal hardware messages, trying to not leak anything into user space but that becomes tricky and error prone.
I think the question here will be how the corresponding messages look on Windows. If they come from "system" they can probably come from this thread in Wine, if they do not, the question is, what sends those on Windows? If that comes, e. g., from DWM.exe on Windows maybe it can be mimicked through this thread too? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10058#note_129215