Function join 

pub fn join<'a, A, B>(
    left: &'a Store<A>,
    right: &'a Store<B>,
) -> impl Iterator<Item = (u32, &'a A, &'a B)>

Every entity present in both stores, in ascending slot order.

Walks whichever side is cheaper to scan and probes the other, which is the whole reason a sparse set is worth having: membership is an array lookup, so a join costs one scan rather than the product. The order is the same promise the stores make on their own.

Cheaper means the slot span, not the component count. Store::iter walks sparse, so its cost is the highest slot ever occupied — a store holding three components scattered across a million slots is expensive to walk and still O(1) to probe. Choosing by component count would pick the wrong side exactly when the difference is worth having.

Both directions yield identical sequences, so which one runs is invisible to callers and cannot reach the state digest.

Deliberately a free function rather than a method: it belongs to neither store, and making it one store’s method would suggest an asymmetry the operation does not have.