When two sends are performed in parallel on a socket the send which came second to server's (socked_send) will always considered blocking if the first send hasn't performed set_async_direct_result() in client's ntdll yet. Similarly, if select() is coming shortly after send() it may report socket as not write ready. We don't care for avoiding a race here because if those two sends or send / select are not synced by app it is unlikely possible for an app to depend on which gets processed first, and the one which was called earlier in wall time now also is not guaranteed to be actually processed first.
The patches fix Tekken 8 which gets frequently disconnected from multiplayer matches. The game treats WSAEWOULDBLOCK from send() on its non-blocking UDP socket, as well as the same socket not reported as write ready from select as a disconnection condition. Those conditions normally (outside of actual network problem / contention) only happen due to the races described above (while the game performs send() concurrently from different threads or is racing send with select).