There's a hanging issue when specifying the collectionUUID parameter to a Rename for an unsharded collection on a sharded cluster with participant shard(s). There could be other commands with logic similar to Rename that are affected (e.g. possibly Drop and ShardCollection) but this was only attempted and observed with Rename.

From a conversation with max.hirschhorn@mongodb.com, it seems like the problem lies in Rename's policy to broadcast the _shardsvrRenameCollectionParticipant command with the expectedSourceUUID and expectedTargetUUID to all shards even when those shards don't own any data for the collection. Upon issuing a Rename, the unsharded collection's UUID is successfully found on the coordinator shard in the kCheckPreconditions phase, which then allows us to continue to the kFreezeMigrations and kBlockCrudAndRename phases. The coordinator shard sends the Rename to participant(s) as-is with the collectionUUID parameter, which will always result in a CollectionUUIDMismatch error since the collection is unsharded and therefore doesn't exist on the participant. The coordinator shard must retry _shardsvrRenameCollectionParticipant until it succeeds on all of the participants to avoid the Rename succeeding partially only on some shards. But the Rename won't ever succeed when the collection doesn't exist on the participant and the collectionUUID parameter has been specified.