Who has complained about this? Can we see the reports?

@Marco,
could you detail which widgets have their mouse focus disabled ?
as there some bug reports wishlist about the issue you mention ?
Honestly I would argue that the disabled feature are all design choices and should not be worth an option for disabling.
Besides, depending on the widget set that is affected, it might bring inconsistency to the style, or even break some applications.

There's no tickets. This change is the result of a QA session over at Netrunner where we noticed the following behavior pattern for the tab bar widget:

1. If you just click a tab, there is usually no focus indicator line shown
2. If you use the Tab key to reach a tab bar by keyboard, the indicator line is shown
3. The indicator then remains shown when using arrow keys or the mouse
4. Once a different control is clicked, the indicator moves, and does not show again on a tab when clicked

This is different to e.g. checkboxes, where the indicator is always shown, whether clicked or tabbed to.

I.e. tab bars have some extra smartness where the indicator is only shown when initially focused by keyboard.

Marco's patch attempts to generalize this smartness so that the indicator is generally only shown when a control is focused by keyboard.

This also helps fix some bugs where some dialogs have a focus indicator shown on the tab bar when they are opened and some do not, depending on which control was set to have default focus in the code. Sometimes switching tabbed dialog pages also moves the indicator to a random control for the same reason.

I personally can't confirm the "like GTK+" thing. While it's true GTK+ seems to have less of the last kind of bugs, with tab bars I've seen both behaviors inconsistently there (sometimes smart, sometimes not) and checkboxes always show the indicator on click.

I think if well-tested this change could be pretty cool. I also think it doesn't need an option and should just be on.

It definitely should not be an option. Either it's better, then it goes in, or it isn't, then it doesn't.

In D5429#101847, @colomar wrote:

It definitely should not be an option. Either it's better, then it goes in, or it isn't, then it doesn't.

Agreed.
If indeed it fixes bugs and inconsistencies (rather than introduces some, as I first wondered), then it should go and remain.

In D5429#101848, @hpereiradacosta wrote:

In D5429#101847, @colomar wrote:

It definitely should not be an option. Either it's better, then it goes in, or it isn't, then it doesn't.

Agreed.
If indeed it fixes bugs and inconsistencies (rather than introduces some, as I first wondered), then it should go and remain.

I think it does make sense to always set this behavior for checkboxes and tabs, i think it makes apps look less busy indeed.
I would drop the option and this behavior on buttons and comboboxes tough (i think if netrunner wants to have buttons always the same colors should be possible to achieve with color schemes tough)

Why do buttons and comboboxes need the focus indicator on click (vs. keyboard) more than checkboxes and tabs, though?

For comboxes at least, once focused (mouse or keyboard), when you press up and down arrows, they change selection. So focus should be there I think
For buttons, same thing. You have a button group, focus on one button (mouse or keyboard), then press the arrow keys, you focus the neighbor buttons.
So focus on the first button is important too, I'd say.
Now in fact, this is also true for checkboxes.

For tabs, this is true only if they get focus via keyboard.

So: if you want to make buttons and others consistent with the tabs, you would also need to disable keyboard navigation for a widget which have been mouse focused.
Not sure this is what you want ...