As far as I can tell, the XMLHttpRequest spec makes no such guarantees.
Generally, browsers tend to view implicit ordering of requests as a problem (referred to as head-of-line blocking), and try to avoid it.
With HTTP/1.1, to avoid head-of-line blocking, browsers open multiple TCP connections to a single origin. If R1 and R2 are sent on different TCP connections, nothing can guarantee their delivery order, because either could be subject to arbitrary network delays.
With HTTP/2, browsers may open just one TCP connection, meaning requests will arrive on the server in the same order they were sent by the browser. So the ordering might hold de facto with HTTP/2. (Obviously, even if it does, it’s only up to the point where the server parses those requests and starts servicing them. For instance, if your HTTP/2 connection is terminated by nginx, it will dispatch requests from one connection to multiple workers as soon as possible. In other words, it might be tricky to “ignore load balancing” in practice.)
But, again, this is seen as a problem with HTTP/2, and a solution is being developed in the form of QUIC, which is UDP-based and therefore loses ordering between multiplexed connections again.