Here’s a vague description of what was needed: Type A is a set of types {A, B, C}. If I need to create/alter A’ while editing A, I spawn a new tab with A’. If I finish editing A’, I can close it and move back to A, or perhaps I’ll create D since I need to add D to A at some point. As this is all very confusing, you could accidentally close an unsaved tab, which is what this aims to solve.

There is an argument that could be made for shifting views from List->A->A’, but since A’ is also on the main list it was confusing. The need was to be able to begin editing of one group from within the edit view of another group. The tabular solution was used to allow maximum flexibility to the user.

There are other places where we use a single Save/Cancel outside a set of tabs for just that reason, but that is where a single object spans multiple tabs.

Conceptually, tabs are a space (and time) multiplexing of a related _set_ of data. Therefore it doesn’t make sense to save only part of that set (but not the rest). Logically, it is an inconsistent update.

From a more pragmatic standpoint, the convention is that the transactional controls (Save, Cancel, Apply) appear *outside* the frame of the tab pages. Users are therefore used to having Save (or Cancel, etc.) apply to all the content on the tabs. If your UI doesn’t work that way it will violate their expectations.

I would strongly recommend modifying the interaction design of your application so that it works in the conventional, expected way.