Define how block settings should be presented in the UI

Cons: Will this always work inside React?

I don't see why not? I'd like to see @bnjmnm comment on this aspect.

Cons: What if we want to map field values to block settings? (see 📌 Define `props` in the context of Block components Active )

ℹ️ I'm assuming that by , you mean DynamicPropSources aka product requirement 7.1 Token.

Why would that make sense? Isn't that what Block plugins already have the context functionality for? This sounds like it'd be a confusing duplication of that functionality. IMHO we should limit

2. Use the block config schema to build a settings form

Pros: Autogenerated forms will be easier to handle in the client
Cons: What if ::blockForm() allows dynamic values or uses other advanced features of forms?

This cannot work AFAICT.

See my detailed write-up at #3462241-8: [PP-1] Decorate the SDC plugin manager and allow components defined in code →

One possible idea is to converge these two options: for fully validatable blocks, allow the block plugin to opt out of providing a form, and automatically generate it from the config schema instead.

Interesting idea! 🤔 But … config schema is not rich enough in its metadata to convey everything. Lots of validation constraints use logic to define valid values, conditional values, and so on.

Hence it sadly follows that it's impossible to auto-generate equivalent forms from a fully validatable block plugin's config schema! 🫤

Is there a third option somewhere in the middle here where some components are flagged (e.g. via hook_block_alter for blocks) as being 'simple' in so far as keys in ::blockForm map 1:1 to their settings. Even if they're not fully validatable.
For these we can call ::blockForm and make use of the existing FormState react functionality to keep the store in sync.
For items that we review and determine that there's more going on in ::blockSubmit ::blockValidate we make a round-trip back to the server to resolve props from form values.
I think there's going to be enough use cases for something like this that we can make it generic on the Component config entity, i.e. the UI should be simple and not need to know the difference between blocks and SDC and anything else added later, it should just know that some components need a round trip to Drupal to transform form values into settings/props - whilst others don't. There are cases where we will need this for field widgets (e.g. ::massageFormValues) and places we will need it for SDC (think Media widget where we resolve an image URL via a hard-coded attributes approach atm).
Thoughts?