What problem does this address?

#80814 added the responsiveEditingEnabled editor setting, which hides the "Responsive styles" option in the View menu and the viewport state control in Global Styles. That covers the global surfaces of the style-states feature — but the block-level states control (BlockStatesControl in the block inspector, covering viewport and pseudo states per block) has no equivalent setting.

Plugins and site owners that curate the editing experience — for example, ones that provide their own state-styling UI — can adopt responsiveEditingEnabled for the global surfaces, but the only way to suppress the block-level control today is CSS against an internal class name (.block-editor-global-styles-state-control), which is fragile and unsupported.

What is your proposed solution?

A sibling blockStatesEnabled editor setting, defaulting to true, settable through block_editor_settings_all — following the same pattern as richEditingEnabled / codeEditingEnabled / responsiveEditingEnabled:

add_filter( 'block_editor_settings_all', function ( $settings ) {
	$settings['blockStatesEnabled'] = false;
	return $settings;
} );

When false, BlockStatesControl is not rendered. Same semantics as #80814: the setting only hides the UI — state styles already stored in content, and the styles they output in the editor canvas and on the front end, are unaffected.

Context

We build a plugin that ships its own per-block device/state styling system, and with #80814 we can now hide the responsive surfaces the supported way. This setting would let us (and anyone else curating the states UI) drop the last CSS override. It's the same opt-out feedback from the responsive styling Call for Testing that motivated #80814, applied to the remaining surface.