Why do we need to use this context system?

Using the context system can be useful for the future, so that this component can read from it — for example, I can see how a parent NavigatorProvider could "sync" with a nested NavigatorProvider.

The contest system is a core functionality for the new generation of components that we've been building. Using it here would also align this component to what we recommend in the contributing guidelines for new components.

But I also understand if at this point we may think this is not needed.

I guess I'm usually in the camp that if you don't need it now, don't add it because you don't know what you'll want to do in the future, priorities can change...

Why do we show a view at all, this is probably going to create an extra div for nothing.

Having a wrapping div around all the "screens" made sense to me, and I think is going to be necessary to fix the scrollbar bug (flagged initially here) by setting overflow: hidden on it.

On top of that, it offers a component to attach a forwardedRef to, together with all of the remaining props that may be passed to this component (given that we mark its props as WordPressComponentProps).

I don't like overflow: hidden as a way to solve the scrolling issue, we can't use as otherwise we may risk hiding popovers shown inside that div potentially. For me it's more a way to hide the issue and not solve it.

What is this for?

It connects the component to the Context System, so that the useContextSystem can be used to read from the context. It also does more, like forwarding refs, adding a display name and a CSS selector (see here).

It is a core functionality for the new generation of components that we've been building.

I guess the same question above applies here.

What does WordPressComponentProps do? In other words, why NavigatorScreenProps is not enough as Props type for this component?

This is the basic type that we've been using for all recently-built component's props (definition).

It augments NavigatorScreenProps with all of the props that a div HTML element may accept. In this case, the false means that we're marking NavigatorScreen as non-polymorphic.

What does View bring compared to div?

View is the basic building block of the components library. Every component that has been build recently uses View under the hood. In its default state, it renders a div, but it then enables other features (like polymorphism)

Looking at the code of the View component, it's not clear to me what that does bring to high-level components?