It's one thing to keep old the old API for backwards compatibility it's another to lack a new API for the new UI.

>The API to render a Windows 11 native context menu does not exist.

My comment was not about that. That lack of API situation is unacceptable from my point of view, but I'm not terribly surprised about that when we're talking about Microsoft.

My comment was about the paragraph starting with:

There’s a meme about how there are at least ten different design conventions in Windows 11 and it’s very much “in your face” once you start using Windows 11 on the daily.

A lot of the examples of inconsistent UI in the article are things built into Windows. For example the "Windows security center" vs. "Eject disk" context menus. I think it's fine for third-party apps to have differences in UI based on their vintage, but why are Microsoft's own apps and utilities all over the map? Microsoft has also done a really bad job of evolving existing UI frameworks. Instead they seem to replace the whole thing every few years with something new and shiny which leads to even more inconsistency. The article lists all of these:

> There is Windows Forms, WPF, MAUI, UWP, WTL, WinUI, MFC, and I am sure others that I am missing.

As a Windows user starting with Windows 3.1 and ending with 7/10 (as a support person for my family), I'm well aware how this inconsistency piled year over year.

During my regular Windows user years, I used to follow Redmond's side closely too. From my understanding, there are some factors contributing to current state.

The leading reason is "backwards compatibility at all costs", including but not limited to how programs behave. It's known that until Windows clamped down on security hard, older Windows programs used whatever functions they can find from .dlls, and also used "bugs" to achieve what they want. So, any changes which might affect how an older program look or feel are strongly frowned upon.

Windows is a gigantic codebase, and until semi-recently, Windows team didn't know what depended on what (the biggest revelation was printing support needed GDI, which brought all UI toolkit in, hence building a CLI only Windows was impossible). So, I'm guessing they're not entirely sure which parts of these applications are used by 3rd party applications. So they leave in, as-is, so nothing breaks.

The latest layer is the Microsoft's culture of "no polish, just new features" mentality. There's a very revealing writing by someone in Microsoft NT kernel team who said that "We can optimize something, but the change will be reverted, and you'll be berated because new features are much important than improving existing others, because new features are which make headlines and bring more revenue in".

Personally, I don't think that Windows team cares much about UI consistency and some other excellence. It's just a cash-cow and enabler of other applications, that's all, and while I'm not a Windows user, I find it sad.

No, this is a non-problem. If Microsoft stuck with Win32, just like how Apple stuck with Cocoa, this wouldn't be an issue.

It's a problem according to the author. Both the lack of an official API for the latest iteration of context menus and existence of older UI artifacts are presented as "paper cuts" and disorienting.

I'm not stating whether it's a problem or not, just iterating/expanding on what the author have said.