MacOS used to have a choice between Carbon and Cocoa, didn't it? Maybe still does.

C++/WinRT uses XAML. But XAML isn't a control library/toolkit. You can tell because it isn't called the Extensible Application Control Library. I'd say it shouldn't be included in your list, but MFC/ATL is just a way of accessing Win32 via C++ -- it makes the same function calls -- so it's not clear that your purpose was to make a fair statement about native development, but perhaps to complain about Windows turnover of apis.

On Linux, it's quite simple to live entirely in Gtk-compatible land. I think Firefox and JetBrains are the only foreigners I use on my box, but I'd be using them on any opertaing system so it's not exactly a fair cop.

Let's go with a file picker dialog, a simple OS-provided component. Windows provides three versions of this dialog (the "app" view, the tree-view, and the explorer-in-your-app view) depending on which API you use. You see this pattern repeated. It being the same calls "underneath" is true, but it's also irrelevant, as the user experience noticeably changes depending on which API is invoked.

> MacOS used to have a choice between Carbon and Cocoa, didn't it? Maybe still does.

It did. Carbon was the pre-NeXT widget set and compatibility to run pre-OS X apps. It is very dead. There is only Cocoa.

> MFC/ATL is just a way of accessing Win32 via C++

Okay, so we can still regard MFC/Win32 as the standard API?