The reason these UDP packets arrive so closely together is because the source and destination are the same machine for both packets.
Not really. 2 independent packets can arrive closely together in any order-- the fact that there's no latency locally is irrelevant, because it doesn't matter how long it takes the packet to arrive, it only matters how long mIRC takes to *read* the packet queue. If you saturate the receive queue of a machine so heavily that the vast majority of the packets are yours, eventually you will get such a collision-- it's basic statistics. Even if only 1 of every 100 packets got hijacked, that would be significant after a very short amount of time. Also realize that in a real world scenario, both clients would be remote, so the local thing doesn't apply anyway. It would be fairly easy to write a proof of concept for something like this.
Honestly, I think the way mIRC relies on a $sock() call to retrieve things like the remote IP and port is flawed from the beginning.
Nothing is flawed, because it worked fine before. This is nothing but a regression. The design of the system is fine, and there's no need to break backwards compatibility and change functionality now. In any case, there's also no reason to add bloat by creating extra event-specific identifiers when a socket-specific identifier makes perfect sense in a single-threaded environment. In a single-threaded environment, per-socket data is *equivalent* to locally-scoped data.
