Neither does GTK, Qt or pretty much any other toolkit I've used. It's not exactly a great example of a standard widget.
We could also limit our definition of modern UI toolkits to only ones that support the Touch Bar and POWER9, but it's kinda silly. The vast majority of interaction metaphors are the same between systems. If your OS has a different or unique function that the vendor wants to see used, it's up to them to expose it well.
I'll give you the touch bar, since that very much does interact with the way GUIs work, but if your graphical toolkit needs to care about the CPU architecture at all I feel like something has gone terribly wrong. The closest thing that seems reasonable is to allow graphical acceleration, but requiring even that is a great way to ensure that things will break on a regular basis.
In theory yes, but the attempts I've seen at this run into issues with things like widgets present on one platform not being present on others (e.g. Win32 has no miller column widget like Cocoa's NSBrowser) and the UI toolkit chasing identical behavior between platforms.
For this sort of idea to work, I think an approach that fills gaps (following previous example, providing a Windows implementation of a miller column widget to mirror NSBrowser) and doesn't try to fight the behaviors of the UI toolkits it's built upon is what's ultimately required. Without that, an approach that reimplements everything from scratch is probably better.