This is a proposal for a mechanism that would allow style variations that are tailored for colors and typesets rather than entire designs. It's common for themes to want to offer alternate colors but without other design modifications. It's also an important consideration for enterprise setups, where smaller units of brand settings need to be passed through to different pages, templates, or sections.

Being able to express a reduced subset of theme.json can help with maintainability and composability. Instead of new API mechanisms for multiple color sets (like #48581 proposes) this instead suggests relying on the same theme.json structure of style variations but determining the relevancy based on what options are actually set.

For example, a registered style variation that only modifies color properties and sets color palettes would not appear as a "browse styles" set but instead become a color preset directly tied into the color panels.

Example:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 2,
  "settings": {
    "color": {
      "palette": [
        {
          "color": "#ffffff",
          "name": "Color 1",
          "slug": "theme-1"
        },
        {
          "color": "#f5b2bc",
          "name": "Color 2",
          "slug": "theme-2"
        },
        {
          "color": "#f5a3ab",
          "name": "Color 3",
          "slug": "theme-3"
        },
        {
          "color": "#560739",
          "name": "Color 4",
          "slug": "theme-4"
        },
        {
          "color": "#000000",
          "name": "Color 5",
          "slug": "theme-5"
        }
      ]
    }
  },
  "styles": {
    "color": {
      "background": "var(--wp--preset--color--theme-4)",
      "text": "var(--wp--preset--color--theme-3)"
    },
	"elements": {
		"heading": {
			"color": {
			  "text": "var(--wp--preset--color--theme-2)"
			}
		},
		"button": {
			"color": {
					"background": "var(--wp--preset--color--theme-2)",
					"text": "var(--wp--preset--color--theme-4)"
				}
			}
		}
	}
}

Such a set would show up to be selected within the "colors" tab in global styles and other relevant interfaces. Themes could register alternate palettes without forcing the "browse styles" UI which aggregates and assumes changes to virtually anything.

The UI representation can thus be paired down to just alternate color sets.

Likewise, font pairs or single font typography scales that apply throughout the design can be defined as simple json variations that only touch typography properties.

Example:

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 2,
	"settings": {
		"typography": {
			"fontSizes": [
				{
					"name": "Small",
					"size": "13px",
					"slug": "small"
				},
				{
					"name": "Medium",
					"size": "20px",
					"slug": "medium"
				},
				{
					"name": "Large",
					"size": "30px",
					"slug": "large"
				},
				{
					"name": "Extra Large",
					"size": "66px",
					"slug": "x-large"
				},
				{
					"name": "2X Large",
					"size": "96px",
					"slug": "xx-large"
				}
			]
		}
	},
	"styles": {
		"elements": {
			"heading": {
				"typography": {
					"fontFamily": "var(--wp--preset--font-family--boska)",
					"fontWeight": "500",
					"lineHeight": "1"
				}
			}
		},
		"typography": {
			"fontFamily": "var(--wp--preset--font-family--inter)",
			"fontSize": "16px",
			"lineHeight": "1.6",
			"fontWeight": "400"
		}
	}
}

This would offer type selection at a global level within Styles > Typography.

There are multiple advantages to leaning on a single file structure, particularly as we embrace section specific json files with a higher composability expectation. This expression could allow alternate color palettes for different contexts easily.

The main question is whether the initial performance impact of determining whether properties of a specific kind are being used is a deterrent. Alternatives can include introducing a "type" or some sort of flag as a top level property. I think it'd be nice if we could avoid that.