I think the issue is bigger than what you have fixed in your patch. Under the assumption that _settings_client.gui.developer >= 2 IConsolePrint gets called which might also call NetworkServerSendRcon and NetworkServerSendAdminRcon.

Similarly send(_debug_socket... in DebugPrint might be prone to the same issue, although that would be more "unintended" behaviour: 'send should not be called on the same stream-oriented socket concurrently from different threads, because some Winsock providers may split a large send request into multiple transmissions, and this may lead to unintended data interleaving from multiple concurrent send requests on the same stream-oriented socket' (winsock2 send() documentation). That might be solved easily with a guard in the actual function.

I am wondering what the effect would be of just queueing those debug messages after fputs, and then pushing them to the admins and in-game console from the "safe" thread. In really spammy debug sessions that might create quite a queue in-memory, so we ought to employ a similar check to whether to queue you have added.
That would also have the added benefit of not accidentally passing debug prints as replies to RCons.