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

[Juri Linkov]

> when one creates a new tab with C-x t 2 or C-x t n it gets the same name
> than the current tab. One can rename it but sometimes it's just a quick
> tab that isn't worth renaming, or perhaps it's just a different view to
> the original content and one is happy with it having the same name than
> the original tab, last but not least one might simply forget to rename
> it. All these scenarios aren't properly supported by tab-switch (C-x t
> RET) since it doesn't disambiguate entries before calling
> completing-read, for example by appending a numeric suffix to dups, so
> just a single representative of the homonyms set appears in the list.

How adding a numeric suffix in completions of tab-switch (C-x t RET)
could help to disambiguate the tabs?  If there will be such automatically
generated completions as "same-buffer<1>", "same-buffer<2>", "same-buffer<3>",
there is no way for users to distinguish these tabs.

Only manually renaming the tabs to names meaningful to the user
will help to disambiguate them, for example, renaming them to
"same-buffer<first-part>", "same-buffer<unfinished-reading>",
"same-buffer<will-read-later>", etc.

The package uniquify.el tries to solve this problem with some low degree
of success by trying to provide hints for disambiguating buffer names
by adding some parts of their directory names, for example:
"same-buffer<dir-name-1>", "same-buffer<dir-name-2>".  But no such thing
is possible for tab names.

> OTOH tab-switcher offers to choose between identically named tabs,
> but IMO it's not a very convenient UI (somewhat invasive and doesn't
> integrate with ordinary minibuffer completion), it's not assigned to a
> standard shortcut and it doesn't seem a good idea to me that functions

`tab-list' with new mode more like list-buffers is developed
in bug#38680 and bug#38624.

> named tab-switch and tab-switcher offer different sets of tabs to pick
> from.  Disambiguation may happen at the moment of tab creation or at the
> moment of tab selection, but I think it must happen one way or another

As you said this is a temporary situation before the user decides what
to do with the tab: either to visit another buffer that will automatically
rename the tab, or rename the tab manually, etc.  So it's a non-problem.