Rank all candidates, then interleave families

Interleaving follows mandatory destination selection; it does not replace that selection.

• Before connection attempts, the client MUST sort received destinations using RFC6724 §6. The drawings start from an explicitly supplied already-ranked list; the helper does not implement those rules. All received addresses from both families matter, not just the first pair. Source Address Selection is performed per destination and is outside RFC8305’s destination-ordering discussion (§4).
• The ordered list SHOULD then be changed to interleave families. With the shown IPv6-first ranked input V6-A,V6-B,V6-C,V4-A,V4-B and chosen First Address Family Count1, the resulting example is V6-A,V4-A,V6-B,V4-B,V6-C. The model preserves relative order within each family (§4).
• An implementation MAY favor a family with more contiguous first-family addresses before trying the other. Section8 recommends First Address Family Count1;2 may favor that family more aggressively. The chosen Count2 picture starts V6-A,V6-B,V4-A, then alternates remaining candidates. This is a selected interleaving policy rather than a required universal permutation (§§4,8).
• A stateful client with expected RTT (round-trip time) history SHOULD insert a lower-RTT preference between RFC6724 destination rules8 and9. If it tracks used addresses, it SHOULD insert a used-over-unused preference after that RTT rule and before rule9. These historical preferences must not displace earlier rules (§4).
• This history MUST NOT be reused across different network interfaces and SHOULD be flushed when the attached network changes. An earlier winner on Wi-Fi is not a universal preference for cellular. IPv6-first is the stated host-policy assumption, not a claim that every installation must always put IPv6 first (§§2,4).