Output block support values as custom css properties in style engine

What problem does this address?

Block supports like color currently have a specific css property configured (in WP_Style_Engine::BLOCK_STYLE_DEFINITIONS_METADATA). That means that in CSS we don't have access to those values to use them for other properties, other selectors, in media-queries etc.

Examples:

For outline buttons, we often provide a hover/focus style, which fills the button. eg: button has a border color of #000, a text color of #eee, no background color; When hovered we want to set the background color to #000 and the text color to something else (eg #000). We code this for all color presets we have in a theme, but it's cumbersome. Also when an user is allowed to add custom colors, we don't know what to set the backgroundColor on hover. At the moment we're misusing the text-color attribute for that and on hover/focus set the backgroundColor to currentColor. Which works, but we have to tell our editors to set the text color to the color they want on hover or have to set that in patterns/variations. Which is not nice.
For buttons with custom colors, it's not possible to set hover color at the moment in the editor. As a theme developer I also can't hardcode any CSS values, because they may not look good/be readable with the custom colors.
Also for buttons: Use the border-color on a custom box-shadow
For complex layouts, sometimes gap has to be changed to padding/margin/positioning etc. I've had cases in custom themes were the mobile view was so different from the desktop and on desktop we used normal flex and block gap features, but on mobile we had to use that value on some other property but we still would like the editor to configure the spacing via block tools.

These example include mostly very custom/specific designs, which use custom CSS and can't be handled in the editor/theme.json (and probably never will, because it's out of scope).

What is your proposed solution?

Proposed solution 1: Style Engine outputs CSS variables

I propose that in addition to that property, the style engine also sets a css variable on the block/element.

Example:

color: #ffffff;
--wp--block--color: #ffffff;
background-color: #2c2926;
--wp--block--background-color: #2c2926;

I'm just using a made up prefix here, to avoid any collisions.

In this way, theme developers can reuse the block supports value in any way they need to. Examples include pseudo elements, hover effects, changing it on media-queries (eg dark scheme). This would probably also reduce the times where __experimentalSelector is needed in blocks.

IMHO this could also solve some problems with css "layering" for core/theme/user. I think by using css variables and using CSSs cascading this would work great as well. Because for a block I can define a default value for the CSS-variable but it can be overwriten by a block support, a variation, a style-variation,...

Proposed solution 2: Style Engines output generation is filterable/extendable

I wanted to give this a go in a custom style engine implementation. Unfortunately the BLOCK_STYLE_DEFINITIONS_METADATA is hardcoded/not filterable, WP_Style_Engine is a final class and neither get_css_declarations nor get_css_declarations is filterable. I understand that the style engine is final, because its kind of still in flux. But this would be a great use case for a custom wp style engine implementation - for custom themes that could be interesting, but that's probably another issue.

So I guess this could be another solution, to allow changing the creation of styles from the style engine.

WordPress / gutenberg