http://trac.edgewall.org/wiki/VcRefactoring#SupportforMultipleReposit...

OTOH, with Subversion, each repository has its own r1, so we need a way
to distinguish which r1 we're talking about.
Fortunately, there's already the syntax for restricted changesets,
introduced in Trac 0.10. That syntax is used to "restrict" what's shown
in the TracChangeset view to a given path, like r1/trunk.

Now, if we consider that using multiple repositories is somehow
equivalent to integrating them in a "virtual" tree, where the toplevel
folder is made up of directories corresponding each to a repository, it
becomes natural to use the name of the repository to disambiguate
between revisions. In your example: r1/Y, r1/Z.

For interpreting r1 alone, a "default_repository" setting should also be
enough. Interestingly, this also solves the problem of transitioning
from the single repository situation to the multiple repository one:
simply set the repository which was formerly the only one to be the
default one when you add more repositories. That way, all previously
existing changeset links will continue to be meaningful.

There's similar situation for source: links. The only additional problem
  I see could be that the name of a repository also happened to be the
name of a toplevel folder in the "default_repository".

I believe this could be seen quite often, when people are transitioning
from a monolithic repository, containing toplevel projects, to a
multi-repository setup, with each of the former project getting its own
repository. If you keep the old repository around as read-only, in order
to make to old links work, you could have trouble to decide if
source:X/doc is the "doc" folder in repository X (the new one), or the
"X/doc" folder in the legacy repository.

I don't see a perfect solution to this.

One idea could be to rename the repositories differently in order to
avoid the clash, but that's not always possible, I guess.

Another would be to allow for aliases, in the same way we do it for
intertrac prefixes. That would in addition be handy for being able to
keep the links short (i.e. you could write r1/x even if the actual
repository name is x_project_repository). But this only provides a way
to write unambiguous links, not to figure what to do in case of ambiguity.

I think that if the first component of the path in a restricted
changeset link or in a source: link corresponds to the name of a
repository, then we always take it to be a link for that repository,
even if a similar path could exist in the "default_repository".
It's only if no path is specified (i.e. a normal changeset), or if the
first component of the path doesn't correspond to a repository name that
the "default_repository" will be used.