Today, the ShardingTest test fixture encapsulates all of its necessary setup logic in its constructor. As part of this setup, it starts all of the shardsvr mongods with FCV equal to the last-lts. After the config server is started with the cluster's FCV, it runs addShard on each of the shardsvr replica sets to configure the cluster. As part of the addShard procedure, the config server runs setFeatureCompatibilityVersion on each shard primary so that it can update its FCV document to match that of the config server. This command is run with majority write concern, so there's still a possibility for a minority of nodes on each shard replica set to still be on the last-lts FCV when addShard completes. The ShardingTest constructor just waits for addShard to complete without waiting for replication to complete on each shard. As a result, it's possible for a minority of shard nodes in each shard replica set to still be on an old FCV version when tests begin using the ShardingTest object.

The general solution to this would be to make ShardingTest await replication on each shard after performing addShard to ensure that its FCV is fully up-to-date. If this isn't necessary for most tests, then we can manually do this within disabled_cluster_server_parameters.js since that test requires all nodes to be fully on FCV 6.0 before it can run.