if you repeat your tests you will probably notice, as i did, that the event mostly triggers only once with $sock().rq = 10. this implies that both lines are being put into the receive buffer before on UDPREAD has a chance to trigger, and $sock().sport will quite rightly return the address of the sender of the last received datagram.
the issue is why mIRC isn't triggering on UDPREAD fast enough for the scripter to be able to distinguish between two distinct datagrams from two different senders.
You have a fundamental misunderstanding about how UDP works, and it looks like mIRC now gets it wrong, too.
UDP is a datagram-oriented protocol. Datagrams are individual units, each with their own source IP+port, destination IP+port, and payload. As far as the application can see, they are never combined or split up. Hence, "on UDPREAD" should trigger once per datagram, and it is then up to the script to process as much as it wants from that datagram. All the while, $sock().saddr/.sport should return the source IP and port of that diagram. If two datagrams are received, "on UDPREAD" should trigger twice.
i'm not sure if it's sensible to assume that multiple datagrams could be received in between polls - notice how the article prefaces its example with a word of caution as to its reliability in various ways - but it would certainly explain mIRC's behaviour.
Each recvfrom() call will return up to one whole datagram, no matter how many datagrams arrived before it was called. The word of caution relates mostly to the behavior of the underlying network, not to the behavior of the operating system; the only possible concern is that if the application is not fast enough in processing the incoming datagrams, the operating system may decide to throw away some of them. None of that is relevant to this problem.
Yes, this is a real bug.
