I don't think that adding complexity to the generic request path just so we can make mach ports look like file descriptors is a good trade-off.
I don't understand what complexity you mean? Is this about the added field in the generic reply? It could probably be moved out of there if it's really a concern.
Wrt mach ports, sure can keep them separate from fds, but they would still require the same mechanisms to receive them, as `thread_get_inflight_fd` on the server side, and as the process-wide mutex on the client side, because like fds we still have only one per-process channel to send them over. So IMO in this case it's better to reuse what is there than duplicate it.
And there's nothing that says that `wine_server_fd_to_handle` needs actual files, it should be able to support any file descriptor.
Well maybe, but we wouldn't need the server file object at all. It seems silly to me to have to go through it and extra requests just to send an fd. Fwiw I added a helper for symmetry with the `wine_server_receive_fd` one, but all we would actually need for sending is to export and call `wine_server_send_fd` (and eventually `wine_server_send_mach_port`) from win32u.