In rename across databases a new UUID is assigned for the target collection. However, the idempotency checks in the rename participant assume that either the destination collection will have the source UUID or the original target UUID.

This means that a retry of a rename across databases with dropTarget: true after the rename succeeded will trigger this uassert endlessly, leaving the coordinator in an infinite retry loop with the DDL lock and critical sections acquired, thus causing unavailability for the source and target collections.