Design UX for moving a tab to an existing window

See #2407 for the initial feature request and discussion.

To organize the discussion, I'm splitting off the UX discussion and proposal for this feature into this separate issue.

UX requirements

• One should be able to move multiple tabs quickly. This can be supported with a count prefix. If we had a "dot" (repeat) command, that could be another way to quickly move many tabs.
• The moved tab should be focused after the move. We can add a parameter on the command to leave the focus in the source window.
• Tabs should only be movable to windows with the same privacy state (normal vs. incognito).

Not requirements

• Undoing a tab move via a specific command or a general "undo" command (Vimium doesn't currently have an undo command). The undo would put the tab back exactly where it came from.
• Handling tab groups. I don't use tab groups and don't know how this command should interact with them, but I did notice that the MoveTabToNextWindow extension will preserve the tab group across window moves.

UX options

1) Show a window picker

• Show the Vomnibar with a list of windows, sorted by most recently used, and pick the destination
  window.
• This is implemented in PR #3925.
• Highlight the target window: it would be nice, maybe essential, to highlight the target window that's selected in the Vomnibar (e.g. with a outline around the target window's active tab).
• Chrome has this UX already: if you right click on a tab > Move to another window, it shows a list of windows of the form "'name of active tab' and N other tabs", ordered by most-recently-accessed. Moving a tab automatically switches to it.

2) Move to a window in a direction

• Implemented in PR #4417.
• If windows are stacked, it's unclear how to disambiguate which one is in a given direction, or how to allow the user to move a tab to a window which isn't the topmost.

3) Move the tab to the "next" window, AKA moveTabToNextWindow

• Implemented in PR #4168.
• "Next" could mean the next most recently accessed window, or the next window sorted by creation time. Vimium C implements the latter.
• You can get a window to its destination by repeating this command (ideally via a dot operator) until the tab lands in the correct window, similar to Vim's split swapping commands.
• This is laborious if there's many windows, and it's unclear how to handle windows which are stopped on top of each other, especially if we allow the source window to stay focused, rather than focusing the destination window.

4) Cut-and-paste

• Do one cut command, switch to the destination window, and then perform a paste command.
• Mentioned in this comment.
• This is powerful, in that you can schedule one or more tabs to be moved, then switch to where precisely where where you want them pasted, and then paste. This is a similar workflow to cutting and pasting text across files/splits in Vim.
• We could implement this as a stack, such that issuing several cut commands queues up all of those tabs to be moved. However, this might be surprising, and is more complicated -- if you made a mistake and want to start over, how do you cancel the current stack?
• It's conceptually more involved, and less approachable, than a single command.

Other references

• There's a small Chrome extension which implements just this feature and has some interesting UX choices.
• If we support performing actions on tabs from the Vomnibar (#4611), "move to another window" would be a natural one.

Comments

Of these options, I think (1) is the simplest: it doesn't have any difficult UX drawbacks, and it takes direct inspiration from the way tab moving already works in Chrome, which is a general design goal for Vimium.

What do you think?

Start with the initial request in #2407, then review the existing approaches in PRs #3925, #4417, and #4168. Compare each UX option against the stated requirements for multiple tabs, focus behavior, and privacy state. Done means a single, agreed UX proposal is selected and its open questions are resolved.