Well, I guess this is less a problem of being deaf. Rather it is a matter of opposite points of view. Maybe even imcompatible points of view with respect to the T.C. buttonbars.deaf's dialogue
About your different "configure buttonbar X" buttons:
You use a different icon in each of your buttonbar files for the
+ command: cm_ButtonConfig (#498)
+ button text: Configurer la barre X en cours (Configure current buttonbar)
As a matter of fact, the command behind these different buttons is always the same: cm_ButtonConfig. This command always acts on the currently used buttonbar file, no matter which file it is. So instead of coding this button (differently) in each buttonbar file, it might have been possible to drop this button all together and to assign a hotkey which launches cm_ButtonConfig instead.
About the active button in buttonbar mode:
If we use the buttonbars in buttonbar mode, there can be no doubt about which buttonbar is the active buttonbar. At any given point in time, T.C. displays just one single buttonbar. So this buttonbar is the active buttonbar.
About the active button in menu view mode:
Things are debatable here.
Let's say take the screenshot TC750_buttonbars_bar01.PNG as an example:
The buttonbar which is displayed as a buttonbar inside the buttonbar area is buttonbar 2 (barre2.bar).
You shift-click on the icon for buttonbar 1 (default.bar).
Buttonbar 1 (default.bar) is opened as a popup menu.
If I understand you right, from your point of view the active buttonbar now is buttonbar 1 (default.bar).
If I understand the behaviour of T.C. correctly, however, the active buttonbar still is buttonbar 2 (barre2.bar). It is still displayed as a buttonbar inside the buttonbar area.
Buttonbar 1 is only a popup menu, not a buttonbar.
The idea of this approach is that you can quickly jump to an item located in the buttonbar 1 file (default.bar) without switching away from the currently used buttonbar 2 (barre2.bar).
In pure buttonbar mode the procedure would be:
(1) buttonbar 2 (barre2) is active
(2) click on the icon for buttonbar 1 (default.bar)
(3) buttonbar 1 (default.bar) replaces buttonbar 2 (barre2.bar)
(4) select an item inside buttonbar 1 (default.bar)
(5) click on the icon for buttonbar 2 (barre2.bar)
(6) buttonbar 2 (barre2) is active again
In menu mode the procedure is shorter:
(1) buttonbar 2 (barre2) is active
(2) shift-click on the icon for buttonbar 1 (default.bar)
(3) select an item inside the popup menu (default.bar)
(4) the popup menu closes automatically
(5) buttonbar 2 (barre2) is still active
Personally I like this menu mode approach very much, much better than looping through various buttonbars. Using the menu mode, I can have my personal default.bar visible all the time. Nevertheless I can access the other buttonbar files easily by temporarily opening them as popup menus.
(As "show as menu" has been activated here for all buttons meant to open another buttonbar file, it is not even necessary to shift-click on the buttons, a simple click will do.)
All right. As we obviously look at buttonbars in buttonbar mode and at buttonbars in menu mode from opposite points of view, we will very likely never agree on the question whether the current implementation of buttonbars in menu mode is consistent and logical and user-friendly. I hope I have made my point clear, if not to you
, perhaps to other readers 
. So I will call it quits for now.Kind regards,
Karl
I love these “flag buttons”, and my damaged fingers say No ! to the keys…
VG