This will be an important server side function to retrieve a data-relational representation since the navigation block can have other blocks in the mix that are not relevant.

Do we have an example of what this API looks like and what it might return (eg either a rest call / php or JS function signature)? This would help me understand the usecase

I had in mind something similar to the nav menu walker but taking advantage of the built in object tree representation of nested blocks to be used in server-side context (could be exposed in REST as well), excluding any presentation specific elements.

Regarding what constitutes the content to be returned by this API, I'm thinking of linking blocks in any flavor (Navigation link, Social links, Home link, Site Title/Logo...), but not other functional blocks like Search, even if it is not a presentation-specific element. Does that make sense, @mtias?

Are there two parts to this task?

1. Add some function that gets a header template part and gets the navigation blocks in that template part
2. Add an API in the Navigation block that can create a tree data representation of all the blocks that act as links

Without (1) how would we know where to find the blocks?

I don't think we need (1) at the moment, as the Navigation block can be placed in other template parts or posts. I can see designs having a Navigation block in their Header and Footer template parts, or different headers with different navigations, and nothing prevents them from having more than one Navigation block instance per template part.

Starting with (2) would allow wrapping items properly when rendering the frontend as suggested in #31951 (comment). Furthermore, it could also help render responsive menus by outputting different HTML for smaller screens excluding the non-content blocks.

I think I described (1) incorrectly. I meant from any generic template part a function that would get the name of the template part and the name of the block that we're looking for and gets that block back. I don't think we have such a thing.

Starting with (2) would allow wrapping items properly when rendering the frontend as suggested in #31951 (comment). Furthermore, it could also help render responsive menus by outputting different HTML for smaller screens excluding the non-content blocks.

I'm not sure using this for rendering is the right track, because it's shifting away from the block rendering paradigm (which should itself be able to support this use case).

Perhaps this could be something that's not so much navigation block specific, but instead works on the basis of the HTML markup. That would ensure third-party blocks aren't left out of the mix.

It could build a hierarchy of the links inside a <nav> element. Any such utility could still work on the basis of a specific navigation block if needed, it'd just use the rendered output.

The other thought I have if this path isn't considered viable is that this could take advantage of the experimentalRole property on attributes to try to apply some semantic meaning to attributes.