MongoS write commands may trigger metadata refresh based on errors other than StaleConfig. In particular, this is what's happening in the coll_epoch_test1.js test.

If a collection gets unsharded on one mongos and a write is scheduled against a different mongos, the second mongos will use a stale config server optime. Because of this, if that read hits a stale config server secondary, it won't see the change in the sharding state.

This is an inherent problem, which can only be solved through the support in the causal consistency project, so this ticket is filed just as a placeholder for versions prior to 3.6.