The "internalRenameIfOptionsAndIndexesMatch" is an internal command designed specifically to be used by $out. It renames a collection but fails if the indexes or options of the destination collection which is being overwritten by the rename do not match those of the source collection. $out works by writing the data to a temporary collection and then as a final step uses "internalRenameIfOptionsAndIndexesMatch" to replace the existing collection with the new data.

For $out in sharded clusters, the node executing the $out always targets this command to the primary node of the db primary shard. My understanding is that this targeting behavior is acceptable because the db primary is supposed to coordinate DDL commands. However, the command is not sharding-aware in that it looks like it always performs the rename locally. If either the source or destination collections are unsplittable collections placed on a different shard, then the "internalRenameIfOptionsAndIndexesMatch" becomes a distributed operation. This situation will be possible once we allow unsharded collections to move rather than requiring them to reside on the primary shard.