While this is somewhat true (especially from Win8 onwards), one of the reasons you have "old-style" menu as a submenu is completely different: it is to make less calls to ContextMenuHandlers, used exactly for "all the third party items". It was a great addition in Win95. By the time of WinXP it was a source of many problems, but of course it was shitty Windows being shitty and not a 3rd party app problem.
The Apple way might have been to take away those old Config Panels with no replacement for years, or ever. Or breaking third-party File Explorer extensions and forcing devs to rewrite them.
Even assuming it is "zero sum" that this Settings page took resources away from other Settings migrations, it's still a net win for "Settings all in one place" isn't it? (In which the article also points out is unlikely to be a "zero sum" case here, because the whole point of using React Native is so that the team that is in charge of "account.microsoft.com" directly can own the Settings page and can share code in it with what they also run on account.microsoft.com. It seems highly unlikely that that web-based team has any other older Control Panel they "own", and more likely that if they own their own Settings page that a team that does own older Control Panels and new Settings pages doesn't have to "moonlight" or "hand hold" the web team's Settings work.)
Realistically, Server 2012R2 was the last release that had full parity between features and matching configuration 'screens'.
Since that time (so: Server 2016, 2019 and 2022, and to a lesser extent the consumer SKUs), configuring new features has required PowerShell and/or WMI. This trend is unlikely to reverse anytime soon. Mostly because features are increasingly complicated.
With Windows 10 and, especially, 11, the GUI parts of the configuration have been redone on a "whatever looks good and is usable for 80% of non-advanced users" basis.
That this now requires "web" technologies is disappointing, but unsurprising. There just isn't a good "native GUI" story right now: not in the open source world, but especially not with Windows or macOS.
Which it should.
Window should be PowerShell-first, and GUI eventually. Even more, GUI should use PowerShell so that you can configure stuff via GUI and export the script for automation. This then leaves to anybody to create GUI if they want, and GUI is just a PowerShell frontend.
- parts from win8
- parts from win7
- parts from something that resembled winXP
- some obscure settings that felt unchanged since win2k
That was it for me, never logged into Windows since, don't know if it got better or worse.
Windows isn’t good all the way through.