Thanks for your comment. I don't want to relitigate or re-open the other bug, but I wonder if you could provide some additional context for the decision to make the default for ctrl-tab be 'move to next spatial tab' rather than 'move to last tab'.

The long version is scattered across various bugs for this, but the brief version is:

(1) Physical traversal is immediately comprehensible to someone pressing the button for the first time.  MRU switching is more challenging to grasp, especially because there's a distinction between "ctrl-tab-tab" and "ctrl-tab, ctrl-tab"
(2) The behavior of physical traversal is always predictable no matter what state you're in.  The behavior of MRU is less predicatble the longer it's been since you last switched tabs (since you need to remember your prior tab order).
(3) MRU switching works very well for use cases with a small number of tabs but scales very poorly into the general case.  With 30+ tabs, MRU switching isn't a feasible method for keyboard accessibility across the tabstrip.
(4) Ctrl-tab has switched tabs in physical order by default in almost every tabbed browser for the whole existence of tabbed browsing.

Understood, thanks for the detailed response.

However, I think just remembering the last used tab (a single tab) and then having Ctrl-Tab switch to that, then revert back to switching to the 'next' tab would be a very acceptable solution here, and scales well to large numbers of tabs. I think that would cover most situations e.g. I switch from this tab to another one, then have to take ages to find this tab again (although see issue 902902 for another idea related to this).

Regarding user behavior, I think most users of OS that support multiple windows have MRU behavior - e.g. Windows does this, and Chrome OS does this too (see https://cs.chromium.org/chromium/src/ash/wm/mru_window_tracker.h) - it seems particularly inconsistent for Chrome OS to support MRU switching for Alt-Tab but not for Ctrl-Tab!

I'm concerned that proposal would infuriate proponents of both routes.  For physical switching users, you add in the surprising "at first it does something unpredictable", and hinder the most common case, which is to switch to a directly adjacent tab.  For MRU users, you don't actually provide full MRU switching, so you're still inconsistent with an app switcher.

I don't think inconsistency between something that primarily switches among <6 open apps and something that routinely switches among much higher numbers of tabs is necessarily bad.  And consistency with historical browser behavior is good too.  In other keyboard shortcuts, that always beats out pure philosophical consistency: see e.g. ctrl-clicking links (opens in new tab) versus ctrl-enter in the address bar (appends .com).

Ugh, listen to your users... No one, absolutely no one finds spatial ctrl+tab usable or useful.  If "first time users" don't find this immediately obvious, they will quickly find that understanding a useless paradigm will be worthless.

Make it a setting.  It's really really not brain surgery to support both features.

Hello chromium team,

All discussions about MRU order is looks like a sermon about what is bad and what is good, and I think it makes no sense to continue it.

I understand that providing a setting for "physical" / "MRU" tab switching in browser core is a big work.
The main question is:

If I'll provide a pull request on github with such feature (can't promice but it's worth a try), it will be just closed or is there a chance to merge it in some time into master (if it will fit all requirements, etc)?

It will be closed; the core team won't accept such a feature at this time.

We will likely accept PRs (or, more precisely, CLs + review requests; the Chromium development process is not quite like on Github) to improve areas that hinder extensions from providing good MRU tab switching to users.  I think today extensions can't bind things in the way they need to provide a great experience here, which is a problem.  Since extensions are the approved route forward for MRU tab switching, I'd focus on making that feel seamless.