>> Rationale: The `@node` command is tightly bound with a section
>> command like `@chapter`; this gets reflected by the command
>> `@xrefautomaticsectiontitle`, which makes `@xref` and friends
>> actually print the sectioning title instead of the node name.
>>
>> For the `@anchor` command, however, there is no such pairing. This
>> means that currently a third argument must be added to `@xref` to
>> get the desired effect.
>
> I get the reasoning, but it is not clear to me why one would want to
> use something else than the @anchor argument for a link. There
> aren't much constraints on anchor content, except that it should be
> unique. I do not get what the second argument to anchor would
> correspond to besides controlling directly the output of @ref in a
> more centralized manner (but only inside a manual not for cross
> references).
At least for the LilyPond documentation, there are various reasons.
* For translators, having the same anchor name as in the original
document helps a lot in translation. And vice versa, it helps
maintainers who don't speak the particular language to still do
various maintenance tasks easier.
* It helps avoid issues with transliteration. All redirection file
names are in a single language, namely English.
* With my suggestion, if a `@node` gets converted to `@anchor` for
whatever reason, all references from external files appear exactly
the same if `@xrefautomaticsectiontitle` is active – and LilyPond
has *a lot* of external references... Without it, the reference
suddenly shows something else, and it would be necessary to modify
the reference command by adding the old sectioning name as a third
argument to get that back.
Werner
