If the config.system.sessions collection is not in the sharding catalog, it's unclear whether the drop should be applied to all shards or just the config shard, because either of these could have occurred previously:

• a previous drop attempt failed partway, and setShardVersion did not get sent to all shards
• a previous drop attempt succeeded, and the user created their own config.system.sessions collection, which would have been created on the config shard

I encountered this while working on SERVER-42842. Dropping config.system.sessions is not really supported, and the behavior before SERVER-33973 was to run the drop only against the config shard, so that is the behavior I am preserving under SERVER-42842.