>> So, maybe these bindings should not be done?
>
> Too late for that now, but they should definitely be done in a way that
> users can customize, without having to advice tab-bar--define-keys (and
> tab-bar--undefine-keys).

Thanks for bringing up this issue.  Customization of keys was not supported
since no once asked for it, I guess because tab-bar--define-keys
respected the existing global keybindings before defining own.
But indeed this doesn't work for local keymaps.

> Maybe by using a mode map?  If there is some reason this cannot be
> done, then maybe a "dummy keymap" could be used?  (User could then
> manipulate the fake tab-bar-mode-map like any keymap, but the bindings
> it contains would then somehow be "transplanted" into the global map
> by tab-bar--define-keys.)

Just adding a simple mode map completely makes it customizable
since 'define-minor-mode' is able to pick it by naming convention:

  (defvar tab-bar-mode-map
    (let ((map (make-sparse-keymap)))
      (define-key map [(control tab)] #'tab-next)
      (define-key map [(control shift tab)] #'tab-previous)
      (define-key map [(control shift iso-lefttab)] #'tab-previous)
      map)
    "Tab Bar mode map.")

The rest of complexity in the following patch comes
from the need to address the customization of
'tab-bar-select-tab-modifiers'.

There is a slight backward incompatibility for users who have own
global keybindings for C-TAB.  They will need to unbind these keys
in the new map.  Then this change should be announced in NEWS: