At the moment, the solution for this issue seems to be adding custom JS to the </body>. While this works, it’s not exactly user friendly (you need a basic JS understanding to add or change links), and could break at any time with a code change to Discourse.
I’d like to suggest the following 3-stage rollout:
Provide a site setting for admins to add external links to the topnav. The site setting will need 3 values, I propose a comma separated list. title,tooltip,URL
Provide a site setting for admins to add internal links to the topnav - without handling breadcrumbs.
Improvinate #2 by handling certain cases where breadcrumbs make sense, like Tags, Users, Groups, Badges, etc.
The benefit to the 3-stage rollout is that external links require no routing by Discourse, nor breadcrumb support. They should simply be an href. Keeping steps 2 & 3 separate will allow for complaint driven development. Roll-out internal link support, see if there are complaints about the lack of breadcrumbs. Meta already has 2 internal links without breadcrumb support, and I’ve never seen a complaint.
Well, sort of, until it gets enough traction or customers asking for it, then it gets adopted by the Discourse Team, which makes it more accessible to hosted sites (granted, I realize not all plugins are available for hosted sites)
I have no qualms with it being an officially supported plugin, however:
I assumed from Jeff’s comment above he supports this feature in core.
The plugin has known issues - including for the specific use case (topnav) that I’m looking to have supported.
Plugins are more complicated for sysadmins to handle. They require ssh access to the server, are updated independently, break more frequently than core (less tests), and are a sticky subject for hosting (which plugins go for which plans).