Style is just one of many things. And it's extremely hard to properly code your own consistent UI toolkit.
On top of that every platform has a myriad of platform-specific behaviors that people expect and that you will get wrong in yours. Accessibility is the big elephant in the room. But even things like secondary focus in prompts/dialogs on MacOS (that Apple's own Catalyst and Swift forget about) is a bitch and a half to get right.
Rust is a nice language for that since it is already a "next-generation" language in terms of memory safety and its momentum is still building. Projects like Druid, while far from ready, are a good starting point.
Which means "unsexy" things like accessibility get left by the wayside. And your users suffer.
Writing a UI kit is a huge task. It's one of those things (like so much else in our industry) where you can fairly quickly climb "stupid mountain" by getting a pile of shiny widgets on the screen; but then you look out over the valley below and realize that, holy, crap there's a whole other mountain range of things that a UI kit has to do.
It's also a tough story for Rust, in particular, because copying what other people have done with other toolkits won't really cut it. Rust's ownership semantics and general opinions don't necessarily accord well with the highly object oriented and event-loop / object-tree structure of most existing GUI toolkits.
Aside: I still don't understand why things like Electron based apps are so bloated. They seem to static link whole chunks of their own (forked) Chromium. But both Windows and Mac OS ship native webview components as part of their system which can be used instead. I've done this myself (used Edge's Chromium webview component in a VST synthesizer, and equiv webkit stuff on Mac) and binary sizes were entirely reasonable. Linux was a slightly more complicated story.
This is why Rusts' "Are we GUI yet?" and posts like this are a good thing. Eventually some new toolkit will arise that ticks all the boxes. We are not there yet and it will require a huge amount of work.
> Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.
Yes, and no. When these widgets try to mimic platform-native widgets we have the uncanny valley problem which makes everything feel out of place like you describe. But if we drop this constraint and design widgets with their own consistent style within the same app, we don't have this problem. Apps like the JetBrains IDE's and Todoist show that this can be done.
To me the middle-ground solution is a UI toolkit with its own widget style, that has some tie-in with platform-native things and conventions like windows, menus, notification trays and keyboard shortcuts. Essentially GTK or Qt without the focus on pixel-perfect matching of platform-widgets. I think this is what Druid is doing. Rust is in a good place for this as it is a modern language that works well on all of these platforms, with no native UI toolkit yet and a package-manager/build-system that supports multi-platform library configuration.
There will always be a place for platform-native apps but cross-platform apps have different requirements. I don't care that my todo list application or IDE does not look exactly "native" on my Macbook. However I do care that these applications look and feel similar when I use them on my Macbook vs on my Linux machines or Windows laptop. Preferably without dragging in a full web-based rendering engine a la Electron.