I think for colors, if you set an empty palette [] and set custom to false in theme.json the control disappears entirely, so maybe something similar could work here too

@mtias and @youknowriad I confirmed that this doesn't actually work for colors. Setting the values in the theme.json as specified still just shows the default palette.

These are the relevant parts of the theme.json config that I have:

{
	"version": 1,
	"settings": {
		"color": {
			"custom": false,
			"customGradient": false,
			"duotone": [],
			"gradients": [],
			"link": false,
			"palette": []
		}
	}
}

And this is what I see:

Setting gradients or palette to false causes errors just like duotone.

Since there isn't already a system for disabling block supports via theme.json, I think having a separate setting to enable and disable them makes more sense. Palettes are used outside of block supports, so it may make sense that you want the supports disabled, but you still want the color/gradient/duotone palettes in other places like for border color for examaple.

I propose adding a block-supports option directly under settings to enable or disable the supports.

{
	"version": 1,
	"settings": {
		"block-supports": {
            "alignWide": false,
			"color": {
              "__experimentalDuotone": false,
              "background": false,
              "gradients": false,
              "text": false
           }
		}
	}
}

We default to having all block supports enabled. Setting to a value of false disables the block support. The support won't be added unless both the theme and the block have it enabled.

What do you think?