Dear ImGUI is just retained mode under the hood, with the name of the widget acting as the index. The API presents immediate mode, but it isn't really. If a "good" immediate mode API just hides all the state under the hood, then I think one should call it something other than immediate mode.
The thing is, immediate mode UIs are not really usable, because a widget needs internal state, so a pure immediate mode UI would require the caller to carry around all that state. Obviously that is burdensome, which is why Dear ImGUI hides it for you. But in my opinion, it's a bit of a fraud to call that an immediate mode UI, when it retains a copy of state behind its back.
The person who coined the IMGUI term (Casey Muratori) literally defined "immediate mode gui" as a concept relating to the API/facade, regardless of what the UI system internally owns or store or manage.
So basically you are dismissing an existing definition to turn it into your own to say that existing libs are not fulfilling that definition.
Since words have to mean stuff, I would definitely call it immediate mode, it's not trivial at all to hack a generic retained mode UI library into being as flexible to what's on screen as ImGui. A generic retained mode design would more rather require pointers to some dependency state to check per update, with ImGui the schema gets rebuilt constantly, instead of being reactive. And there is definitely use cases for this design, constantly changing stuff would probably fit with Dear ImGui or others better than with a generic retained mode UI toolkit.
