In SERVER-65340, we are discussing that if a sharded cluster performing a rename operation reaches a point where it cannot roll back a rename operation, it's going to continue retrying indefinitely. So, writeConcern.wtimeout should not be provided to a renameCollection in a sharded cluster.

We can make this behavior clearer:

• here
• and in the writeConcern field description here

Additionally:

• "Resource locking in sharded clusters" could be clarified to include reference to majority write concern, as is described in the writeConcern field description
• There may be other operations that should be similarly clarified (cc pierlauro.sciarelli@mongodb.com can you suggest others?)