I'd like to see a middle ground between immediate mode and retained mode, where the UI is more like a scene-graph where you have nodes with transforms, but you can draw anything inside them, and the framework will keep track of all the matrix math for you like a game engine would. Maybe no one would find that useful, but its something I'd like to tinker with.
My personal IMGUI library [1] is what I call "partially retained" in that there is an immediate mode API similar to dear imgui or nuklear on top, but under the hood the immediate mode API just manages retained mode object graphs for you automatically.
This is a fantastic (imo) way to build user interfaces, because sometimes the most convenient way to manage state or construct a complex widget is to write a retained mode object that hosts some other child objects, and in other circumstances it's most convenient to write a modal dialog or something by just slamming out some imgui code in a standalone function.
I also think the imgui approach to layout (use an algorithm that can fully reconstruct your layout from scratch every frame without much of a performance penalty) removes a lot of potential bugs and quirks that are common in UI, like one-frame glitches or having to manually propagate state through a bunch of objects and layers. Though imgui approaches have their own downsides, like the "page tearing" issue. I've had to do some weird contortions to solve that one in my own code and I still get bugs occasionally.
The game I'm building right now does almost all of its scene layout and UI as a single graph of components that mix retained and immediate mode, and it's been a relaxing way to do things compared to the 'manually paint widgets in places and do hit testing' approach I've used for some previous titles.
A large portion of the UI is constructed via what I'd call 'value replication', where a container control is attached to a list of game objects (entities, components attached to entities, parameters to a script) and then the container automatically creates a list of child controls for each game object automatically. This allows easy virtualization (i.e. only having 20 controls to represent a scrolling view with 1000 items) and means I don't have to manually do a bunch of state synchronization.