Well, I think it is quite possible that the devs on the first-party team are not the same devs on the platform team. First-party or not, if the platform provides the tools and the devs refuse to use them, it is on the devs. Not the platform, the devs. Unless you can show me where the company demands its devs do so for no good reason.
>> I bet somewhere in there there's still UI that dates back to Win3.1.
I'm sure there is, that's a mix of backwards compatibility and don't mess with stuff that works. Some people want it, some people don't; can't make everybody happy. Can I complain that OS X provides a terminal that looks like it dates back to the 70's?
> Especially since Terminal.app is far more modern than CMD.EXE?
To be fair, a lot of Terminal.app dates back to ancient Mac OS too. The menu bars, for example, are all still Carbon. There is still a full classic Mac OS main loop running alongside the Cocoa main loop in every macOS application. Apple's done a good job hiding it, but it's still there.
Anyway, cmd.exe is a bit of a special case. What you're really seeing is conhost.exe, which is kept the way it is because it's part of CSRSS, which occupies a similar place as PID 1 does, and Microsoft doesn't want to bring new UI into it for fear of increasing its dependencies [1].
The 3.1 UI that still exists is silly stuff like file open dialogs that aren't "desktop aware" or whatever. There's no reason at all to retain such "compat" because it instead requires users to learn where all such magic folders live in the filesystem.
>> I bet somewhere in there there's still UI that dates back to Win3.1.
I'm sure there is, that's a mix of backwards compatibility and don't mess with stuff that works. Some people want it, some people don't; can't make everybody happy. Can I complain that OS X provides a terminal that looks like it dates back to the 70's?