In reply to Helen Hou-Sandi.

When we say educational issue, we're generally referring to people not being aware of things like the purpose of the Customizer (as the people actively developing it see it) - being much broader than just themes and theme options, its extensibility in themes and plugins (which the new documentation should help), its incredibly powerful and well-thought-out API, etc. We generally define the Customizer as "A framework for live-previewing any change to WordPress." Customizer-related development has generally centered around that idea for some time now, making adjustments to allow the UI to better scale to our anticipated future needs as we work on adding features like this. The thing with menus is that theme locations could already be changed in the Customizer, so with that moving into the new menus panel, we aren't actually adding any new top-level UI to the Customizer with this change.

There's also the broader issue of people not understanding how core development works, or how decisions are made. There was a comment on Chris Lema's post claiming that "This should have been developed as a plugin, like MP6" (paraphrasing), which sums this issue up pretty well I think (in case anyone missed it, the plugin has been in development for the past year and the post on make/core was a feature plugin merge proposal).

Many of the commenters on the make/core proposal very clearly didn't read that post. I'm guessing they came from here, or eventually might have just followed a link from twitter and built off of the concerns that some the initial commenters expressed with the proposal to remove the admin screen. As of now all that's been decided for the admin page is that it'll continue to be developed as it has been for a while now (with a few improvements here and there, but likely nothing major), at least for now. That being said, those working on the Customizer would like to get there eventually and I could see us doing it on the timeline in the post even if the broader core development community isn't willing to commit to that just yet.

I'm generally not a fan of the phrase "core team," because it could be taken to mean a lot of different things and generally implies a closed group. Sure, I could be considered part of the "core team" in that I contribute pretty significantly to core, focusing on the Customizer in particular, but technically speaking I would be considered a "core contributor" or "contributing developer". I'm also officially a "component maintainer" for the Customize component, meaning that I have developed a deep understanding of it and work to manage the tickets pertaining to the Customizer. But by nature of the process, those proposing a feature-plugin for merge don't really get a say in whether it's approved. Their work is generally going to be considered in regards to their other core contributions, though; if a lead dev proposed merging a plugin, it'll almost certainly be approved by other contributors because they've built up a reputation for doing good work in core. It's important to remember that WordPress is a meritocracy, not a democracy. More info (partially outdated, but mostly accurate) here: https://make.wordpress.org/core/handbook/project-organization/.