Yes, I perfectly know this. But unlike what you imply, you cannot know when a TCP packet is lost, because it's all dealt with at the TCP stack level and the application doesn't know whether some packets got lost and re-transmitted or not for any given TCP connection (such as an HTTP one). The "packet loss" reported in the viewer exclusively deals with UDP packets, just like the bandwidth limiting setting. At the application level, the only sign of (irrecoverable) packet losses in a TCP connection is a timeout (when re-transmitted packets don't go through or not fast enough).
I replied to the problem as you posed it yourself. Citing you " teleporting into a new area, can flood/max out a connection (
massive packet loss) causing rezing to fail among other issues."
No, the problem is with the network buffer queue on your router/MODEM and the absence of proper QoS. Without any QoS to prioritize packets, high bandwidth connections are filling the queues (which are made up very large buffers to maximize the maximum bandwidth) and the next outgoing UDP packet (that would require a high priority to be emitted before the queued data pertaining to the high bandwidth connection) is then queued and must wait for the queued data before it to go out before it can be emitted in its turn. With nowadays routers/MODEMs, buffers are so large that it can take several seconds for them to empty out, causing apparent "packets loss" (actually timeouts waiting for the reply to a packet that might still be stuck in the router/MODEM queue), followed with "out of order" packets warnings in the log (when the reply to the packet that finally left the queue arrives while that packet was already flagged as lost by the viewer).
The true solution to your problem is not to limit your HTTP traffic, but rather to configure the QoS on your system (do a search on the Internet for how to do this: there are plenty of good tutorials for each OS).