It certainly would seem that way, but I think I've found a way that doesn't require the tabData information (see attached).  It's a bit kludgy in the sense that

+              tbar->setCurrentIndex ((index + 1) % tbar->count ());
+              tbar->setCurrentIndex (index);

i.e., selecting some other tab and then going back to the current tab, appears to grab the focus.  Otherwise, I can't think of any way of causing a focus without knowing that tabData because internally the QMainWindow keeps an associated list

info->item_list.at(i)

in which info is a structure holding the list and the info->tabBar.  I suppose that since main_window is inheriting QMainWindow we might be able to access some of the internal variables, but I'd rather than do that and if they are private then they are not accessible.

(file #44143)

I think there might be such a signal:

http://doc.qt.io/qt-5/qtabbar.html#signals

Probably tabBarClicked().  It might be difficult to get at in the QMainWindow environment or it could involve a dynamic connection as these tab groups appear.  For example, the following signal should be emitted when a widget is docked or moved elsewhere

http://doc.qt.io/qt-5/qdockwidget.html#dockLocationChanged

Then one could check the tab stack it belongs to and make sure that tab stack has tabBarClicked() connected to some new routine that will move the focus to the parent window.  Most likely disconnect-then-reconnect so that connections don't build up with each focus change.  Or something like that.  If a tab stack disappears, it's connections should automatically go away.

Low priority, as it isn't too difficult clicking inside the content of the QDockWidget.

A very minor detail, but if there is a tab stack in the main GUI or in the variable editor mouse button press on the tab of the visible panel in the stack does not bring that item into focus.  Attached are a couple screen shots which show that nothing happens when I pressed the mouse button right where the mouse cursor is shown.  That is, I tried to activate the Command Window by clicking the visible tab...nothing happened; focus did not transfer to the Command Window.  Of course, had I moved the cursor up and clicked in the actual Command Window, then focus would change.  Note that if the item in the tab stack is not the visible one then clicking on that tab brings the item to the front of the stack (i.e., visible) and gives it focus.

I'm attaching a second screenshot that illustrates the same thing happens with the Variable Editor.

Either something related to main_window::focus_changed (QWidget *, QWidget *new_widget) has to be changed, but I doubt that can be done because that slot is connected directly to the qApp signal that indicates somewhere focus has changed.

Instead, it looks like something in the label_dock_widget, which is a base class of both octave_dock_widget and variable_dock_widget, has to be changed.  Either it could be something having to do with focus proxy, or perhaps one will have to write a short mouse-press event handler for the tab buttons and change focus even when the top stack tab is pressed.