>> > I prefer to allow this kind of customization, especially for
>> > functionality that is of a wide interest, through options or
>> > variables, rather than the customization API, as the former would
>> > be easier for users and also less likely to break.
>>
>> It is always better indeed. But it also gets easily complicated to
>> cater with all the possibilities. For this specific example, there
>> should be two different options node/href, replacing an existing
>> button or adding another with the same name should be
>> distinguished, the user may want to have the button prepended or
>> postpended, only for headers and not footers, only if split at
>> nodes... Also, to do the same in the default case for global
>> directions, you need to specify description, accesskey, rel... I
>> think that it would be better to make it easier to do it with init
>> files rather than try to have an interface for all the
>> possibilities.
>
> Good point. Perhaps we should provide a stable customization API
> for navigation buttons only and document it well, as it seems like a
> fairly common thing that people want to customize.
What you are discussing now is waay beyond what I had originally in
mind. In hindsight it was a bad idea to show my crude customization
try, since this incited your imagination far too strongly :-)
Meanwhile I believe it would be fully sufficient for most users to add
a Texinfo command that specifies a node name for a section that
contains the index (or indices), and which is then used accordingly in
the navigation bar, for example
```
@indexlink Indices
```
Werner
