InnerBlocks inserter shows all blocks and causes editor confusion

Summary

A recentish change in Gutenberg appears to make the InnerBlocks inserter show the full block catalog instead of a constrained, contextual set of child blocks.

This creates substantial confusion for editors and undermines the intended nested block model. In practice, it becomes much easier to insert irrelevant blocks into structured areas where the parent block is clearly supposed to guide or limit composition.

Why this is a problem

The current behavior causes a few issues at once:

• Editors are presented with many irrelevant block choices inside controlled layouts.
• The UI no longer clearly communicates the intended structure of the parent block.
• It increases training and support overhead because people assume all shown blocks are valid choices.
• It becomes easier to break layout or content assumptions in patterns based on nested blocks.
• The broad inserter behavior feels inconsistent with how InnerBlocks is typically used to create guided editing experiences.

Expected behavior

The inserter inside InnerBlocks should respect the intended child-block context.

Depending on the block setup, that usually means one or more of the following:

• Respect allowedBlocks
• Respect parent / ancestor / child relationships
• Respect template intent and editing constraints
• Prefer a contextual inserter over showing the full global block list

At minimum, the editor should make it clear why a broad set of blocks is being shown if that behavior is intentional.

Actual behavior

Inside an InnerBlocks area, the inserter shows all or far too many available blocks, including blocks that are not meaningful in the given parent context.

This creates mass confusion for content editors because the UI strongly implies those blocks are appropriate to insert there.

Steps to reproduce

1. Create or edit a block that uses InnerBlocks.
2. Configure the nested area with a constrained structure, such as allowedBlocks, a template, or a parent-guided layout.
3. Open the inserter inside that InnerBlocks area.
4. Observe that the inserter shows the full block list, or a much broader list than expected.

Impact

This is not just a cosmetic issue.

It affects:

• editor usability
• content governance
• structural consistency
• trust in block-level constraints
• the usefulness of nested block authoring patterns

For teams building curated editorial experiences, this behavior makes InnerBlocks feel unreliable as a guided composition tool.

Environment

• WordPress version: latest WordPress version
• Gutenberg plugin version: latest available version
• Block setup: mainly custom blocks and custom nested block setups
• ACF: issue also appears in ACF block-based setups
• Theme: custom theme
• Browser: reproducible across all major browsers

Additional notes

If this behavior is intentional, it would help to document the rationale and the recommended way to preserve a constrained inserter experience.

If it is a regression, restoring contextual inserter behavior would significantly reduce editor confusion.

If this behavior is here to stay, developers need an official way to customize it without relying on hacks, workarounds, or CSS tricks.