Add a config (and gitattributes) option annex.userkeystring , such that git-annex-add (and calckey) will include this string in the key. If the string is 'UUID' then a uuid (or shorter random string) will be included instead.

From ?support longer file extensions:

"The way git-annex picks extensions doesn't need to be stable across all versions of git-annex, because it's only done when initially adding a file, and then the key, with whatever extension, is added as-is and git-annex does not care about the extension thereafter."

Then, for an MD5E key, the userkeystring can be included before the extension: MD5E-s0--d41d8cd98f00b204e9800998ecf8427e.USERKEYSTRING.txt . Cleaner would be to add a field to the key, as in MD5E-s0-uUSERKEYSTRING--d41d8cd98f00b204e9800998ecf8427e.txt , if that wouldn't break compatibility.

This enables attaching metadata not to file contents, but to the file itself; or partitioning keys (and therefore key metadata) into namespaces. The downside is some loss of deduplication. This loss may be acceptable. The loss can be mitigated for local repo and non-special remotes: after storing an object with e.g. MD5 d41d8cd98f00b204e9800998ecf8427e under .git/annex/objects, check if there is a symlink .git/annex/contenthash/d41d8cd98f00b204e9800998ecf8427e ; if not, make this a symlink to the object just stored; if yes, erase the object just stored, and hardlink the symlink's target instead.

Closing since external backends is implemented, and you could do this using it. Whether that's a good idea, I'm fairly doubtful about. Be sure to read "considerations for generating keys" in

done --Joey