SERVER-134162 was caused by DSC replication code assuming that the members array in the replica set config is always listed in _id order. That assumption does not hold, as Atlas makes no guarantee about member order, and reconfigs routinely produce configs where members are out of _id order (for example, new electables inserted ahead of an existing read-only node: [_id: 1, _id: 0, _id: 2]). The skip-self check in heartbeating was the instance that surfaced in a HELP ticket, but the DSC coordinator still uses a member's array index as its identity in other places, such as populating primaryId and senderId in heartbeat requests from _selfIndex and tracking the current primary as _currentPrimaryIndex.

The impact is that any of these index-as-identity uses is a bug of the same shape as the heartbeat bug: it works on the initial config, where _id happens to match position, and breaks only after a reordering reconfig. We do not exercise reordered configs in our test suite.

We should move DSC replication off array ordering entirely, identifying members by _id (or by host, where the code already resolves that way) wherever it currently uses position as identity. We should also add test coverage that reconfigs with reordered members and verifies heartbeats and primary tracking stay correct.