Looks like a side-effect of Apple’s use of an overlay-style file system (e.g. OverlayFS or UnionFS). These file systems combine two or more physical file systems in a way more complicated than the traditional mount point mechanism used by HFS+.
These mechanisms are intended to hide the structure of the underlying file system volumes, allowing volume-level protections to be applied at what seems (to the user) to be at a per-file or per-directory granularity. They also allow copy-on-write semantics, so users that “edit” a file end up secretly making a copy, leaving the original intact in its original location.
Given the error reported by CCC, it would appears that it is accessing the underlying volumes (probably necessary for a reliable clone) and is not going through the normal overlaid file system. But it is definitely Apple’s bug that renaming the overlay doesn’t propagate down to the names of its underlying volumes.
I can think of two possible fixes:
- Apple updates the Finder so renaming an overlay-volume causes the underlying volumes to be appropriately renamed
- CCC adds some logic to check for this. Verify the name against the Finder-visible name and then go look up the names of the underlying volumes.
Given what I know about the people/companies involved, I suspect the latter will be more likely to happen.