Jeff King [off-list ref] writes:

But here's the interesting part: it breaks a bunch of tests. They all
seem to be doing things like ":file.txt". In check_filename() right now
we treat that literally. But as a pathspec, it is technically "colon
followed by zero or more magic signature letters", and it is eaten.

Hmph.  Shouldn't the definition be "colon and then one or more magic
signature letters", then?  ":file.txt" to name the blob object at
path file.txt in the index is fairly common "rev" and it is a shame
that it has to become ambiguous with a pathspec element.

So I wonder if we have painted ourselves into a compatibility corner a
bit, if we have two conflicting expectations. We might be better off
just teaching check_filename() to parse multiple of [^/!] and the
trailing colon. It's horrible and not great for maintainability, but
this syntax is not something that changes often.

Ah, OK.

So the idea is that when given _as_ a pathspec element (e.g., after
an explicit "--" separator), we do want to interpret ":file.txt" as
the same as "file.txt", but when dwimming to sift revs and pathspec
elements apart, prefer to take it as a blob object name in the
index?

I guess that would work better than the current code (or straight
"use the full pathspec parser" approach) from the compatibility
viewpoint.

Thanks.