Workspaces: Integrating Interaction Modes - Proposals
In this task we can discuss possible solutions for integrating interaction modes with workspaces nicely. Thereby the requirements of T53388 should be met.
Proposal 1: Mode only stored in the workspace
Conceptually, it makes sense to have the interaction mode in the workspace. That way it becomes a workspace-global setting that only changes when users do so themselves or by changing the workspace.
It meets requirements #1 and 3 (see T53388). For requirements #4 and 5, the workflows would have to be redesigned and rewritten. However doing so may be quite challenging.
Active object would probably have to be stored in the workspace, so that switching workspace may not lead to having an object in a mode it doesn't support (requirement #2).
Requirement #6 is more of technical nature and doesn't matter for this proposal.
By placing the mode selector in the top-bar like planned (see T50845), requirements #7 and 8 are addressed too.
Proposal 2: Keep mode per object, workspace can change it
We keep the mode stored in the object, but allow the workspace to change it. It means we keep old workflows intact, while still making the mode a per-workspace option (requirements #1, 3, 4 and 5 are meet).
Issue is, with the mode stored per object, activating a different object may cause the interaction mode to change. Hence, the mode would have to be synced with the workspace. However, for this proposal, just like for proposal 1, we'd need to store an active object per workspace to meet requirement #2. So we had to sync the active object with the workspace anyway.
For requirements #6, 7 and 8, the same as in the first proposal applies.
Conclusion
Both proposals would suggest to store an active object per workspace. Moving the mode completely to the workspace may make more sense long-term, but the second one seems far more feasible. The syncing of the workspace mode and the object mode basically comes for free due to the active object per workspace. We could even avoid storing the mode in the workspace completely (its active object stores it indirectly).
A user visible difference is that in the first proposal, the mode would never change except if users explicitly do so or change the workspace. That's different from how Blender behaves now (pre 2.8).