bug#51935: 29.0.50; tab-switch hides identically named tabs

[Juri Linkov]

> Tabs are positional so the position can be used to disambiguate
> choices. I would use it as a suffix but only where it helps
> disambiguate options.

Tabs are positional only when the tab-bar is enabled and visible,
especially after customizing tab-bar-tab-hints to non-nil.

But the problem is that 'C-x t RET' is used mostly when the tab-bar
is disabled and not visible, so tabs are not positional in this case.

> That said, I believe even "same-buffer<1>", "same-buffer<2>",
> "same-buffer<3>" is preferable to nothing, first because it's the same
> in tab-switcher, tabs are all named equal and it's only the position
> that distinguishes them, adding a sequential number conveys the same
> information than the position in the tab-switcher menu, so if that's
> good for one case it's likely good for the other one as well, at least
> as long as it doesn't make completion cumbersome, which is the case
> when it's a suffix sparingly added; second, because as it is today one
> gets the impression that tabs are missing, it can get pretty
> confusing, more confusing than arbitrary suffixes I would say. Notice that I
> don't use the tabbar (and I believe I'm not alone in that respect) so I rely
> on the tab list to get an overall picture every now and then, sometimes to
> figure out what tabs need renaming.

If this problem exists for completions candidates of 'C-x t RET',
then we could add the suffix <N> to non-unique completion strings
with tab names here.