to some extent retained mode is a cache invalidation problem. imgui's sidestep this, except for a constrained set of cases where building the ui requires doing a lot of work, in which case a simple, bespoke cache can be used - to me this is far simpler than trying to wrangle your entire application through a generalized state cache abstraction. especially since doing so generally requires you to deeply adopt the UI framework's abstractions into your application code, regardless if it's a good fit or not - like you said, you can avoid duplication, but the tradeoff is massive coupling.

i think a glaring red flag with retained mode ui's is how slow they are. there is a reason they put so much effort into granular reactive updates - they're just way too slow otherwise. resize retained mode ui windows and the fps drops to like 2. meanwhile in an imgui, it doesn't matter if you're rendering 1000 buttons and then need to render 1000 dropdowns, the work is roughly identical. this means big problems for a retained mode system. this seems like a massive issue to me - the system is so slow, it's only considered "faster" than imgui (debatable) when it doesn't actually do much. but we want ui's to scale with interactions, not depend on minimal changes in order to recover acceptable performance.

> resize retained mode ui windows and the fps drops to like 2

This just isn't true? Every desktop application I use uses a retained mode UI and most of them resize smoothly. Most of the ones that don't are electron.

I genuinely don't understand how you can make this claim right after agreeing with me that the only difference is the caching. You can't seriously be claiming that by just adding a layout cache you lose 30x performance?