As jmikola explained in SPEC-974:

In the case of feature compatibility being downgraded, I believe there is still a risk that the client believes a server supports sessions (and retryable writes) when it does not.

Consider that when SDAM is initialized, a driver monitors a primary and sees wire version and logicalSessionTimeoutMinutes, which indicates that the server is feature compatibility 3.6. The driver executes a write command that includes the lsid and txnNumber fields. The response for that command is lost in transit, and the driver needs to retry. Before a retry attempt can be made, the server is downgraded to feature compatibility mode 3.4. The retried write command includes the same lsid and txnNumber. The primary, operating in 3.4 feature compatibility mode, will ignore these fields and apply the write a second time.

The above example considers a downgrade between the first and retry attempt, but a similar race condition exists if the downgrade were to happen between the driver's last monitoring round (issuing isMaster commands) and the write's first attempt.

I think at least one of the following may ensure that there is no risk of ever applying a write multiple times:

• The server must close its connections when the feature compatibility mode is downgraded.
• A 3.6 server should raise an error if a write command includes lsid and txnNumber and feature compatibility mode 3.6 is not enabled.

I believe the error reporting in the second bullet is worth implementing regardless. That would be consistent with what is already done when commands include a collation option on a 3.4 server, and the server does not have feature compatibility mode 3.4 enabled.

Additionally, a 3.6 server operating in FCV 3.4 should suppress logicalSessionTimeoutMinutes from its isMaster response (as originally reported in SERVER-31738).