When I spitballed a lexicon for Stage Manager, I hadn’t yet actually played with the feature. One would think not having actually used a feature would prevent someone from giving feedback. That said, here’s what I suggested regarding Stage Manager specific command+tab and command+` behavior:

Stage Manager introduces a hierarchy that I hope Apple leans into. Windows belong to sets and sets belong to stages. Given this hierarchy, I don’t think command+tab should switch between apps because, just like with existing multitasking, an app switcher can’t work when an app is divided across multiple stages. Instead, I think command+tab should switch between sets and command+` should switch between windows in the set that is currently on stage.

Having now tried Stage Manager using Guilherme Rambo’s Virtual Buddy, I’ve discovered that while command+tab disappointingly still cycles between apps, command+` actually does what I suggested… sort of. It’s complicated. As with everything else with Stage Manager, this complication greatly benefits from establishing some vocabulary. Here’s my heretofore Stage Manager lexicon:

• set — a collection of windows
• stage — a main area of a screen
• strip — where other sets live when they are not on a stage
• stage manager — the mechanism that manages which of the sets are on stage verses those that are in a strip.

As of writing that lexicon, I thought that only sets lived in strips. That’s not the case. In addition to sets, a strip can contain another kind of collection which I’ll call a “stack”¹.

• stack — a collection of windows and/or sets that belong to a single application in a strip

This seems simple enough. The complication and my prior confusion stems from the fact that sets and stacks are visually the same in macOS Ventura. The difference is purely functional. When Stage Manager is first enabled, each window is organized by application in a strip. Windows are then stacked whenever an application has multiple windows. Sets containing multiple windows from the same application are still stacked, while those containing windows from different applications aren’t. Multi-application sets necessarily get their own entries in a strip because they can’t logically be stacked within a single application.

All-in-all there are six possible scenarios of how windows can be organized in a strip:

1. A single application window
2. A stack of multiple windows belonging to the same application
3. A set containing windows from the same application, which could be stacked
4. A stack of multiple sets, all of which having windows from the same application
5. A stack of windows and sets, all from the same application
6. A set containing windows from multiple applications, which can’t be stacked

The nuances of these six scenarios become obvious when invoking command+`. Outside of Stage Manager, command+` cycles through all windows of the current application. When Stage Manager is invoked, command+` cycles through all windows in the current set and/or stack. This works surprisingly well in most scenarios. When working in a stack of windows, pressing command+` replaces the current window on stage with one from its stack². When working in a single unstacked set, command+` simply cycles through the windows currently on stage (as I suggested.) Where Stage Manager’s command+` behavior breaks down is scenarios 4 and 5³. When a stack contains sets, command+` will cycle through the windows in a set as well as all other windows in a stack. In these scenarios, it’s impossible to know whether the keystroke will merely raise the next highest window in the set that is currently on stage or bring forward one along with its entire set from the stack.

While Apple might be able tweak command+` to be more intuitive in scenarios 4 and 5, I don’t see how. Instead, I wonder if sets and stacks should conceptually be separated. Currently in Stage Manager, a window can live in a set and a stack. Conceptually separating sets and stacks would greatly simplify how windows are organized in a strip. Instead of six scenarios, there would be just three:

1. A single application window
2. A stack of multiple windows belonging to the same application
3. A set containing more than one window

I don’t even think making sets and stacks mutually exclusive would be functionally all that different from what Stage Manager does today. By default, windows would still be stacked automatically by Stage Manager and sets would still be specified by the user⁴. Command+` would still cycle stacked windows off and on the stage the same way it currently does. It would also continue to simply cycle through windows in the current multi-window set on stage. The only functional difference would be all sets, even those involving one application, couldn’t be stacked and therefore would always have their own entry in a strip.

Here’s an updated list of nouns in a world where sets and stacks are mutually exclusive:

• stage — a main area of a screen
• strip — where sets and windows live when they are not on a stage
• set — a user-defined collection of windows to be displayed on a stage simultaneously
• stack — a collection of windows, organized by application in a strip, to be displayed on a stage individually
• stage manager — the mechanism that manages which window or set of windows are on stage verses those that are in a strip

Sets make sense. Stacks make sense. Conceptually combining the two is confusing, while separating them simplifies Stage Manager without losing any real functionality.

Updates:

• Having slept on this post, I came to the conclusion that “single-window set(s)” is too tortured, and doesn’t accurately represent Stage Manager conceptually. I have reworded the post to simply use the nouns “window(s)” and “set(s)” in lieu of the tortured “single-window set(s)”.
• Additionally, I added a sixth scenario to account for stack of only sets.
• Finally, I aligned how the current and proposed scenarios are phrased.

Update 2: What I’ve been referring to as a “wing”, Apple now calls a strip as of macOS 13 beta 3.

Update 3: I went ahead and replaced “wing” with “strip” in this post since it published the same day that “strip” was first revealed in macOS 13 beta 3.