Some of the blocks being created for block themes are inherently complex to set up (Query being a prime example). Simplified interfaces are going to be offered through variations (like Posts List for Query) but it still stands to reason that in many cases starting from patterns will be a better user experience overall. Semantic template parts (#27337) are a case that would benefit from a stronger tie with patterns, allowing not just listing them as a design start but also the possibility of swapping them out quickly.

My proposal then is to explore defining an API where a block could be tied to one or more pattern categories, broadly speaking. Blocks connected with patterns could then surface them in the main transforms menu; the sidebar inspector; or other interface elements we build in the future:

Blocks that have placeholder states could surface connected patterns (needs some design explorations) similar to how variations are currently exposed. That might also allow themes to connect their own registered patterns with the block interface — so when a user inserts a group, or a column, they could get fast access to a subset of the patterns a theme registered using those blocks in a contextually rich area.

Defining the API

I believe it to be important to keep this API fairly simple for the benefit of integration and transformations. For example, we could do something like this on the block registration surface:

patterns: [ 'pattern-category-1' ]

We should try to avoid too much introspection, though given the relationship is a loose one, we might need to validate the root block type of a pattern before allowing it to show up, etc (i.e. should a "quote" be allowed to be transformed into a "heading" if the heading was registered as a pattern on a "quote" category?). In more complex patterns with nested blocks (where a block might not have a counterpart in the target pattern) we'll need to decide on some behaviours upon transformation.

There's an angle to discuss where any pattern category matching a block name could be implicitly allowed to be listed, though I think this is better modeled as an explicit block opt-in, hence the patterns: [] proposal.

This proposal can be visualized as a window into the pattern inserter from a specific block context, taking advantage of transform mechanisms when possible, and more broadly connecting our two main content insertion flows.