I don't agree with the first two points. Native applications aren't consistent in this way. There are dozens of cross-platform GUI kits and they all behave slightly different, just like Electron apps. If you want consistency, you need to build multiple apps, one for each OS with their respective toolkits. Ain't nobody got time for that when you can easily build on Electron and target browsers, macOS, Windows, and Linux in one single app. No wonder Electron is winning the battle so far, regardless of your last point.
Native implies that you are building for each OS and their native toolkit. On macOS, you write Cocoa. On Linux you write GNOME or KDE or CDE. On Windows you write...I dunno. Win32 probably.
Current tech is C++/WinRT, for this year, but last year it was WPF and five years ago it was XAML, then previously it was MFC/ATL, and original Win32 somewhere back in the old days.
And Linux isn't better. I think OSX is the only desktop OS that has an idea of what an app should look like.
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.
