Jacob Keller [off-list ref] writes:

I also agree, I'd prefer if we aim for the mapping to be something
which works for all refs in the future, even if such support isn't
added now, which is why i've proposed using "refs/remote/<name>/" so
that a tag would go from

refs/tags/v1.7

to

refs/remote/<name>/tags/v1.7

Ideally, we could work to update "refs/remotes/<name>" to go to
"refs/remote/<name>/heads" as well.

This is *not* imcompatible with having refs/remote-tags/* as an
interim solution.  

We'll have to support refs/remotes/<name>/<branch> anyway long after
we start using refs/remote/<name>/heads/<branch> by (1) switching
the fetch refspecs newer "git clone" writes to the latter format,
and (2) extending the dwim table to try both formats.  Having Wink's
solution as an interim step adds one more entry to (2) but the
machinery is already there.  And it does not change (1), either.