What problem does this address?

At the moment the Navigation editor is designed to work with a very specific structure of the Navigation Block.

The expected structure is a navigation block with mostly nested Navigation Link blocks. When saving in the editor, those links are mapped directly to nav_menu_item post types—the same storage format used by the existing menu editor in WordPress. For backwards compatibility these menu items are rendered using the same walker system as present. Which ensures theme styles still work even with the new block editor interface.

It does support other block types when a theme opts in to this feature—Search, Social Links are a couple. These blocks are saved as html in a custom type of nav_menu_item.

But there are proposals to change the structure of the navigation block significantly. The potential future blocks that are relevant are:

• The (proposed) Links List block. An empty container for any manually entered links.
• The (still undecided) Submenu block. This would be the default way a user creates submenus.

These blocks are more challenging because they contain Navigation Link blocks. Some ad-hoc code would need to be written to be able to convert these blocks back and forth from nav_menu_items.

What is the goal

To make the navigation editor less susceptible to bugs that can occur from changes to blocks, while at the same time providing the navigation block with some scope for iteration.

What is your proposed solution?

My first thought is that we could drop the use of the navigation block in the editor, and build a separate classic menu block for the editor when a theme hasn't opted in. This would make it much easier to manage backwards compatibility.

A second option could be to consider using the transform system for converting from/to menu items, which could allow blocks to define declaratively how they should be converted from block data to menu items. It would be a way to transition from a system that's largely hard-coded and limited to one that's more dynamic, and could support a few different block types (possibly even third-party block types). But I don't think it'd be completely straightforward, the data structures are quite different!

And a third option could lie in the block itself, potentially in a basic mode of the block where it only supports links.