@ellatrix, does lightBlockWrapper handling exist only for backward compatibility? I don't see it used with core blocks anymore. I see it referenced in multiple places in the block editor package. Could we set apiVersion to 2 in a hook during registration to simplify all those checks?

Yes, it's for backward compatibility.

Could we set apiVersion to 2 in a hook during registration to simplify all those checks?

What do you mean?

registerBlockType filter could detect if there is lightBlockWrapper set in supports and when it's true then inject apiVersion with the version 2. Would it be compatible?

Hmm, have we considered updating the selector for getBlockType to return some default not found type, or do we depend on undefined?

Normally we should return the core/missing block type at this point in block list, but it is possible to unregister the block type. Presumably someone can also break it by updating setUnregisteredTypeHandlerName to a nonsense value.

Hmm, have we considered updating the selector for getBlockType to return some default not found type, or do we depend on undefined?

That would be a breaking change. In the current setup setUnregisteredTypeHandlerName is optional for the blocks registry. In practice, it might unconsciously become mandatory. The challenge is that @wordpress/blocks can't provide some fallback blocks like the default one, the grouping one, freeform content, and the unregistered type. Maybe that should be the responsibility of the @wordpress/block-editor package to define some of those handlers so unregistering a given handler would rollback to the built-in one, or it wouldn't take an effect. We could alternatively refactor code to take into account that those handlers might get unset or the corresponding block type can be removed. @youknowriad and @mtias should know better what was the initial design here and what would be the best way to make it bugs free.

That makes sense to avoid a breaking change. If we want to make this a little nicer for callers, one alternative would be to return a default unknown type in the case that the unregistered type handler name is not configured (which supports no properties/has no attributes) in a new selector, say getBlockTypeOrUnknownBlock. In its implementation might simply be something like: return getBlockType( type ) ?? UNKNOWN_BLOCK_TYPE. It wouldn't actually be registered, since I think it's fair to add that level of customization.

I think the current design is fine too provided that all callers know that undefined may be returned from getBlockType. This is easy enough to search for in core usage. We're missing some other usages where we blindly pass blockType to another selector, and that selector does not check for undefined. There's also a few spots in code where we also assume that 'core/missing' is registered.

We can of course guard these in follow up PRs:

does lightBlockWrapper handling exist only for backward compatibility? I don't see it used with core blocks anymore. I see it referenced in multiple places in the block editor package. Could we set apiVersion to 2 in a hook during registration to simplify all those checks?

I opened PR #34459 that removes usage of lightBlockWrapper.