The problem right now the separation of concerns for GUIs is a complete shitshow on ALL platforms.
Even such "simple" tasks as how to composite a window, a video in that window, and a floating menu over that window are not very well specified in any OS (try resizing that window and watch the fun). Or, for example, your floating menu--should the parent window resize itself and paint with transparent pixels in the extra area or should that menu be a separate "window"? And, what does being a "window" even mean?
Add into that the fact that we really should be making multithreaded GUI systems at this point and it's very clear that GUIs are stuck in a local minimum that's really hard to get out of because GUI systems require so many lines of code.
Window resizing works perfectly fine on macOS if you use the native AppKit framework. It’s only when you try to embed a whole different world (Qt, GTK, Flutter, Electron) in your window via an opaque OpenGL/Metal surface that things break/lag/distort on resizing the window, which again is another reason to stay away from these cross-platform GUI shims.
I don’t really see the reason for multithreaded UIs either. A single UI thread works perfectly fine if you move your business logic off to a separate thread. Most people are just too lazy to do that, and start developing their app with the business logic running synchronously on the UI thread; which works for a while, but eventually reaches a point where it starts blocking the UI event loop; then they try bandaging it by moving certain pieces to a background thread and they shoot themselves in the foot with thread-safety issues. The way to solve this is not by making the UI framework multi-threaded… Simply be disciplined with UI ↔ business logic separation from the get go and all these problems go away. Yes, I know it’s so tempting to call the database directly from the button click handler - but don’t do it.
Even such "simple" tasks as how to composite a window, a video in that window, and a floating menu over that window are not very well specified in any OS (try resizing that window and watch the fun). Or, for example, your floating menu--should the parent window resize itself and paint with transparent pixels in the extra area or should that menu be a separate "window"? And, what does being a "window" even mean?
Add into that the fact that we really should be making multithreaded GUI systems at this point and it's very clear that GUIs are stuck in a local minimum that's really hard to get out of because GUI systems require so many lines of code.