The Global Styles architecture and features is growing significantly and the complexity of both the implementation and the mental model is increasing due to the organic nature of the iteration process. It is a good time though to take a step back, take a look at the main issues we're having and how to address them while simplifying the mental model.

Currently supported features:

1. Themes provide a theme.json (styles an settings) file that contain what I'm going to call a style variation. It defines colors, typography, palettes ... for the active theme.
2. The default "style variation" can be edited in the UI and saved in the wp_global_styles CPT in a single entry (per theme).
3. Themes can also provide alternative "style variations" for their themes, by creating new files under the styles folder like styles/red.json or styles/blue.json
4. These variations are not editable in the UI but instead, you can actually copy their content and apply it to your theme in the the default CPT entry for the theme.
5. In 6.2, we introduced the possibility to edit "block style variations" in the UI. So for instance a user can edit the "outline" style variation of a button (apply colors, typography...) and save this in the CPT entry under styles.blocks.core/button.variations.outline. In a way we're using the same theme.json structure and same global styles UI to edit a style variation that applies only to a given block.
6. In 6.6, we're introducing a way to register these style variations that apply to one or multiple block types using files in styles folder and by using the top level blockTypes property to choose which block type they apply to. The structure is very similar to any style variation (default theme.json, red.json or blue.json)
7. 6.6 also offers a way to register the exact same block specific style variations as nested keys (instead of separate files) in theme.json file (or red.json, blue.json) under blocks.styles.variations. The advantage here is that theme authors can define these variations within a parent theme style variation red.json file, so when the user picks the "red" style variation for his theme in the UI, it also changes the styles of the available style variations for the blocks.
8. The block specific style variations registered using the method in 6 or 7 are editable in the UI just like the default block styles variations (see 5) and the changes are saved similarly.

These are great features, but it's easy to see how the multiple ways to write and save these variations can start to become confusing for users, in addition to the complex mental model, here are some issues that were raised before related to this model and some that are more hypothetic issues and features that we'd want to support:

• The issue that comes often, is that people lose their modification of the default style variations (theme.json) when they apply an alternative theme style variation (red.json) in the UI.
• It is not possible to edit the alternative theme style variations in the UI and keep the changes, to go back and forth between the different variations. Any change is saved as the default variation.
• We want to be able to allow users to create and edit style variations in the Global Styles UI.
• We want to potentially support "settings" aka defining palettes in block specific styles variations later. (This basically means the blocks.styles.variations key introduced in 6.6 is not ideal.
• We want to provide an API for plugin authors to easily register alternative style variations.

A potential path forward / proposal

I think there's an opportunity to simplify the mental modal and solve all of the issues above:

• Everything is a style variation. It can be used in different contexts (applied to a block, applied globally) but it's the same concept.
• 1 file under styles in a theme = a style variation = 1 separate CPT entry: this means that style variations are not all saved to the same default CPT entry.
• Style variations can have "metadata" to define where they can be applied: they can have a "blockTypes" config to define if they're global (omitting the key) or apply to specific block types. They can also have a "parent" key to define whether they are style variations that are only available in the UI when you switch your theme to a given style variation. (Addresses the use-case mentioned in 7)
• You can switch to style variations in the global styles UI and edit the style variation that you like using the global styles UI.
• You can switch the active theme style variation of your theme, which actually changes the "id" of the CPT entry used in the frontend.
• You can easily create/edit separate style variations.
• It also opens the door to enable "page specific" active style variation or "template specific" active style variations.

Downside

This proposal mean that the configuration introduce in 6.6 under styles.blocks.variations is not ideal (as it breaks this mental model and becomes redundant) and might get deprecated later. Given how late we're in the release cycle of 6.6, I'm proposing that we deemphasize this feature (not remove it) in the docs / dev notes / theme.json schema... We can introduce a new apiVersion if needed to completely remove it.

I'd appreciate any thoughts on this proposal. Thanks. @aaronrobertshaw @ellatrix @carolinan @richtabor @andrewserong @ndiego @mtias @ramonjd @jasmussen @oandregal @tellthemachines