This is actually a regression.
I see the correct separate source port numbers when running the code in mIRC 6.35.
If there's a design limitation in the way mIRC reads sockets, it's been introduced recently, and I can confirm that this is a bug-- a fairly serious one, since it means a script cannot properly respond to a client if multiple clients send data at the same time. Data can leak from one connection to another-- especially since this bug likely applies to the source address too. Again: this bug means that a malicious user could easily steal response packets from any mIRC UDP server script simply by flooding it with garbage packets while other clients interact with the server normally.
For reference, wireshark shows the following:
7 219.155133 192.168.0.2 192.168.0.2 UDP Source port: 65050 Destination port: vcom-tunnel
8 219.155320 192.168.0.2 192.168.0.2 UDP Source port: 65051 Destination port: vcom-tunnel
mIRC *is* actually sending the packets on separate ports. The problem is indeed that the sockread event is tripping over itself.
