Can we discuss this more before you jump into adding it?

There are several use cases for MRU tab switching between two tabs, but a lot of them are not just switching between one pinned tab and another.  It seems like this doesn't address any that fall outside that, or anything involving switching among, say, three tabs instead of two.

In exchange, the behavior of ctrl-1..9 becomes less stable and predictable.  How do users discover this?

One way we solve some of these today is by allowing extensions to provide MRU tab switching.  Why wouldn't we prefer to e.g. build in a dedicated switch-tabs-using-mru-order keyboard shortcut as opposed to this solution?

What does UX think about this?

This wouldn't be just pinned tabs, it'd just be the tabs you can reference by ctrl+1..9, pinned tabs would be a more clear use case where you expect to have webpage X at the same stable position.

I think a MRU stack is more confusing than letting the existing keyboard shortcuts toggle as ctrl+1 -> ctrl+1 does nothing meaningful. Personally I've always disliked MRU stacks but I'd love to be able to toggle back and forth between two tasks easily.

To me the ctrl+1 -> ctrl+1 toggle is really intuitive for doing so (but I have used it in previous window managers so I'm not a new user here). In short, I've used this for many years and love this workflow, so I'd like for folks to test it out in Chrome.

Mark / Emily, any idea who to loop in from UX here or do you want to make a call? It might be feasible to experiment with an extension here if you'd prefer it, but the overhead of adding this under a flag to Chrome doesn't seem that large.

[On Mac is it currently possible to switch between all tabs (pinned / unpinned) with CMD-1 up to CMD-9. CMD-9 focusses the very last tab, regardless of whether the last one is tab 9 or e.g. tab 25 in the Tabstrip.]

mehmet, that's true of all desktop platforms. This bug is against having control-n alternate tab you started on, and the nth tab. For example, if on tab 5, control-1 would take you to the first tab, control-1 again would take you back to the 5th tab (where you started).

It isn't clear when the code would know control-n should switch back. Only if control-key is held down the entire time? Time delay?

I agree with Peter's assessment and think this would be more surprising and confusing than useful.

Ah, okay. Thanks for the clarification.

I think this might be prototypable with an extension, so I'll throw this idea out for now (I'm not too interested in MRU switching).