Setting enable_on_transitional_fcv: true means that a feature flag will be enabled in the transitional FCV. This means that those feature flags would turn on in a shard as soon as kStart is sent to that shard. In a scenario where the command is sent to a mixed binary cluster (due to administrator error), it would mean that the feature flag would turn on in some shards while other shards are still an old binary. In SERVER-102169 the different scenarios were investigated and there could be a edge case of one shard being on a transitional FCV (feature is enabled), while another shard has a primary with a new binary and old FCV and a secondary on an old binary and old FCV. In this scenario, whatever new field written to the primary will be propagated through replication to the secondary on the old binary.

This scenario could be dangerous depending on the feature, so features that want to set enable_on_transitional_fcv to true should be aware of this and make sure that it could not lead to data loss.

The issue described in SERVER-105970 is another reason to limit setting enable_on_transitional_fcv to true.

Because of this, it would be nice to add guardrails to setting enable_on_transitional_fcv to true (such as through a linter that checks for a comment) and/or add some info to the README about this scenario.