Original text:
that the load balancer will redirect the next Client Initial packet to a different server in that pool.  7. Versioning in QUIC may change the protocol's behavior completely,

Reviewer comments:
Add a section about being careful with timing with respect to CID migration if you actually care about linkability.
Linkability across CID changes is in the common case so trivial that protocol features to defeat linkability through other means risk being useless. "Find CID y where delay < d between last packet for CID x and first packet for CID y on 2-tuple {a,p}, given {x,a,p}" is an operation which requires zero additional state and a simple O(kn log n) search for any large on-path (passive surveillance) device that's halfway smart about keeping per-flow state -- i.e., it's basically a free operation, and its utility is baked into the physics of CIDs -- after all, this is what CIDs are for. The ease of this analysis can only be mitigated by increasing the size of the anonymity set: ensuring that for any given delay window d, a minimum number of CIDs x transition on any given {a,p}. This seems like good operational advice for servers with enough traffic to build such anonymity sets (should they have interest in preventing client linkability, of course) -- small servers are probably out of luck though. Applicability should call this out as a problem, manageability should suggest a solution space.
-quic-transport section 6.11.5. begins to address this now, but aside from the following... URL still seems to pretend that coordinated CID migration is sufficient to fix linkability. So I still think we need something in -applicability. Will throw together a PR today.
addressed in

Revised text:
that the load balancer will redirect the next Client Initial packet to a different server in that pool. <ins> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </ins> 7. Versioning in QUIC may change the protocol's behavior completely,