Harald Nordgren [off-list ref] writes:

quoted

For example, writing "v2.52.0" there to see how far we came since
the last release would become impossible if we always force prepend
"refs/remotes/".  I wonder if we can reuse already existing DWIMmery
that uses refs.c::ref_rev_parse_rules[], which should allow such use
case, while still allowing you to write "origin/master"?

Sounds like a follow-up rather of doing now, right? 🤗

Since the inteface won't change, just adding more functionality a new
feature, we should be able to fix this behind the scenes later.

Disambiguation will make it harder or impossible to add such an
enhancement later, though.

When the user says "git log origin" or "git show origin/main",
refs.c::ref_rev_parse_rules[] is applied and turns these into
refs/refs/remotes/origin/HEAD or refs/remotes/origin/main, but as
you can see in refs.c::ref_rev_parse_rules[], these are at
relatively low precedence order.  Your version has refs/remotes/ as
the first (and only) choice, so if a user has refs/heads/origin/main
and refs/remotes/origin/main at the same time, "git show
origin/main" would use the former.  With the implementation of this
round, "[status] compareBranches = origin/main" would pick
refs/remotes/origin/main and nothing else first, and then would
start behaving differently once such an enhancement to use the
standard DWIMmery rules is introduced, which may appear to be an
unnecessary regression to end-users.

So, no, I wouldn't recommend it as a follow-up.  We should decide to
do so now or declare that we would never do so.