If a replica set is configured in such a way that its implicit default write concern would be {w: 1}, we require a cluster wide default write concern to be set before that replica set can be added to a sharded cluster. This prevents situations where the cluster uses the default of {w: majority} but that is unavailable due to the shard's configuration. It also prevents a discrepancy from emerging in the behaviors of replica sets and sharded clusters (ie. a similarly configured replica set would use {w: 1} but the sharded cluster configuration would use {w: majority}).

However, there is a race condition in which this can happen anyways. The checks for whether the implicit default would be {w: 1} are done via the "isImplicitDefaultMajorityWC" field in a shard server's hello response. This is checked very early in the addShard command, before we do any modifications to the replica set. However, the replSetReconfig checks which prevent reconfigurations which would change the write concern to w: 1 only take effect once the sharding state is enabled and this happens later in the add shard command. So the following interleaving can occur:

1. start with a replica set with 2 nodes, neither arbiters
2. begin add shard and pass the default read/write concern checks
3. reconfigure the replica set adding an arbiter

At this point, the add shard may complete, thus allowing a shard with implicit default {w: 1} and no cluster wide default set.