Google Drive allows two sibling folders with the same name; the "(1)" you see is a local rename by Drive for desktop, and rclone creates the twin

Google Drive is not a POSIX filesystem: two children of the same parent may share a name. Nothing dedupes them, and no API call errors.

How it shows up on macOS: Drive for desktop cannot represent that in the FileProvider mount, so it renames the second one locally. You see

2-drafts
2-drafts (1)

but the server title of both is 2-drafts. Confirmed in the daemon's own metadata (~/Library/Application Support/Google/DriveFS/<account_id>/metadata_sqlite_db): the two items rows carry distinct ids, local_title values of 2-drafts and 2-drafts (1), and both protos contain the string 2-drafts — the suffixed row additionally has a local-title override property. So the suffix is a client-side display fact, not a name you can rely on.

Why it matters: uploads keep succeeding into whichever twin the client resolved, while humans open the other one. A file can be genuinely on Google, with a valid com.google.drivefs.item-id#S xattr, and still be invisible to everyone reviewing the "same" folder. It looks exactly like a sync failure and isn't one.

Where the twin comes from: any tool that creates a directory on a lookup miss. rclone's Drive backend is the common one —

rclone copy /local/2-drafts remote:2-drafts    # creates remote:2-drafts if its listing misses it

Drive answers the duplicate-name create with a second folder rather than an error, so a stale directory cache, a race between two machines, or a partially-configured remote leaves you with twins. rclone ships dedupe precisely because this is expected Drive behavior.

Detect:

rclone dedupe --dedupe-mode list remote:            # server-side, names the duplicates
rclone dedupe --dedupe-mode merge remote:           # folds same-name directories together

On a machine with the desktop client, any (N) suffix in a directory listing is the same signal, and reading the metadata sqlite shows it without touching (or hanging on) the mount.

Cleaning up from the mount, safely:

Verify the id before deleting. The (1) is assigned by the local daemon and could in principle attach to either twin after a restart or re-index. xattr -p 'com.google.drivefs.item-id#S' "$MOUNT/2-drafts (1)" and compare against the one you mean to keep.
Use rmdir, not rm -rf. It refuses a non-empty directory, so a wrong-id verification cannot silently destroy live content. Merge contents first if there are any.
Deletes go to Drive trash (30 days), so this is recoverable, but only if you notice.

One trap while auditing: an unfiltered query of the metadata db shows trashed items too, because deleted-but-not-purged rows keep their parent edges. A duplicate folder that looks like it still holds files can be genuinely empty — filter trashed = 0 before deciding what would be lost. In my case the mount listed the twin as empty while an unfiltered metadata query showed a child directory with two files; the child had already been trashed, and rmdir succeeded.

Environment: Google Drive for desktop 129.x, macOS 25.5 (Darwin), Shared Drive.