The only built-in components of the sidebar are SEARCH, TOOLBOX and LANGUAGES. The rest provides a stable interface that allows customisation and localisation through each key mapping from either a literal text label or an interface message, to a list of similarly structured literal texts or interface messages.

As such, starting such label with an uppercase character is reasonable, common and expected. Most wikis, especially outside WMF, do not need localisation or the complexity and indirection of every word being in a separate MediaWiki-page. And yes, this means #p-navigation might not exist. It doesn't need to as it isn't part of the stable interface from the software. For every script that uses a lowercase ID, there are probably ten more scripts that expect a capital letter for a local section.

There should probably not be production code that expects or otherwise attributes special significance to anything other than the above three reserved items. I understand this is incompatible with Minerva which historically had a hardcoded sidebar with minimal items that facilitated a passive read-only experience. With mobile moving towards providing a more suistainable experience, I don't know if this is still needed. One way to move there incrementally could be to invert the logic from cherry-picking "navigation" to ommitting the sections we think are not yet ready for mobile and/or being considered to phase out more generally on desktop as well if/when we are ready for that research and conversation.

Or to keep it as today, one could generalise how it works by doing explicity what it seems to be intending to do, which is to render only the top section. You can access the first key of an associative array using array_key_first(). Note that the parsed sidebar data is an associative array, which still contains a logical order (and we render them in the same order as they are defined, naturally).

If we keep the implementation as-is, Minerva will likely end up with an empty sidebar on various production wikis and third-party wikis that have chosen to call their first section something else.

There should probably not be production code that expects or otherwise attributes special significance to anything other than the above three reserved item

The Growth team makes some modifications to the mobile "home" menu item on mobile inside Extension:GrowthExperiments so if mobile is going to use MediaWiki:Sidebar (which is a technical goal) we will need to find a way for this link to be identified across all wikis.

The Minerva-Growth hooks currently use n-mainpage-description to find the home link in the section that Minerva refers to as "discovery" and internally comes from p-navigation, and then offers it for modification through a Minerva-specific hook.

The last parts of this seem graceful and can continue to work. Seeding "discovery" with the first section rather than explicitly p-navigation (and thus depend on site-configured labels for that) should work fine either way, Growth doesn't rely on on what the section is called.

In core we already offer hook to support modifications of this kind. Growth could handle onSkinBuildSidebar, and modify the n-mainpage-description item of the first (or any) section as it sees fit. If this modification should remain limited remain to Minerva, the hook also passes $skin to this hook for Growth to vary its behaviour and keep it specific to that skin.

Looking a bit further, I think this hook might not be needed anymore depending on how Minerva will use the sidebar. What the Growth hook is doing is set the label of the mainpage link to "Main page". This however is already the case by default, so it handling onSkinBuildSidebar in this way would be a no-op.

What currently happens: Core sidebar - → site admin override → extension hooks override → Minerva override → Minerva-extension hook override for Growth

It does this because the override in Minerva to refer to the main page as "Home" creates confusion for newcomers as the community they are joining generally refers to it "Main page" and per the "Homepage" feature that Growth provides. If Minerva merges its overrides such that it ensures presence (e.g. add as "Home" if the mainpage link is missing) then this will work (as opposed to re-re-re-overriding the label to Home after site admin and extension overrides).

That would reduce complexity a bit, I think.