Consider the following scenario:

• setFCV on shard0 aborts unprepared transactions
• mongos starts a cross-shard transaction and hands off two-phase commit to shard0
• setFCV starts trying to acquire the global S lock in order to wait for existing (prepared) transactions to commit or abort
• shard0 cannot starts two-phase commit since it needs to persist the participant list and that requires the IX lock on the config.transaction_coordinators collection.
• setFCV needs to wait until the transaction above times out (i.e. wait for transactionLifetimeLimitSeconds) and gets aborted by the abortExpiredTransactions reaper.

SERVER-65821 is introducing a way to allow TransactionCoordinator to bypass setFCV when persisting the commit/abort decision. So adding that to the "persist participant list" step would allow the transaction above to enter prepare and then commit or abort so setFCV would not need to wait for transactionLifetimeLimitSeconds. However, this would allow more transactions to enter prepare concurrently with setFCV and depending on how long those transactions take, setFCV can end up waiting longer.