> OTOH, I can't imagine how you could implement a formatting function
> without requiring two-pass tabs generation that is highly inefficient:
> after the first pass you get the number of tabs, groups of tabs,
> and their names.  Then on the second pass you can pad names
> with required amount of space proportional to the total number of tabs.
>
> So a more efficient implementation would be to modify the strings
> that represent the tab names in the result of tab-bar-format-list
> (e.g. by using advice-add for experimentation).  But a drawback is
> that then you need to rely on the details of implementation of the
> internal data structure.

I still see no other way to implement pixel-based filling/justifying
of tab names.  So here is a prototype to try that later will be adapted
to tab-bar.el.  It seems that's all we can do for nicer-looking tabs.
At least, it resizes tabs like in web browsers.  And the default value
of tab-bar-tab-width-max is the same as in Firefox.