What problem does this address?

One of the aspects of the navigation block discussed in the past has been how it saves its data.

In the past WordPress menus championed reusability, you can assign one menu to multiple locations on a site. When the navigation block was first envisaged, there was a discussion about whether the menu storage system (custom post types for menu items and I believe a 'term' for the menu itself) could be used, but it was decided that a more block-y approach should be taken, preferring the raw HTML output of blocks.

Since then, the way reusable blocks and template parts work has come along way, and it might be time to revisit whether the navigation block could use the same sort of system. This would essentially allow the user to create a menu once and reuse it anywhere on their site, with the blocks potentially being editable from a standalone editor

What is your proposed solution?

Use a similar implementation as template parts and reusable blocks for the navigation block.

Technical complications

I did a quick assessment of what would be required.

Reusable blocks and template parts are wrappers that save all of their inner blocks to a custom post type. The main difference to the navigation block is that the navigation block itself renders a <nav> wrapper and has a considerable number of attributes that also need to be saved and loaded, and from what I can tell, this is a new area yet to be technically explored.

An option would be to create a new wrapping block, but it would have to be interface-less.

Opportunities

The way the 'theme opt-in' in the navigation editor works still needs to be shaped considerably (#33969). There's a potential opportunity that when a theme opts-in to support the navigation block in the nav editor, the editor saves and loads the same custom post type system as the block.