https://github.com/ocornut/imgui/wiki/Multi-Viewports
This is a feature available on Windows, macOS, and of course X11. Making choices like this means desktop Linux becomes even more of a weird island that nobody wants to support.
(None of the above explains why ImGui cannot in the interim accept a janky experience where newly created child windows pop up wherever the window manager puts them, as commonly happens for transient dialog boxes. This seems like a nice to have feature, but not a complete showstopper.)
It's also worth noting that that imgui wiki link says the feature doesn't work well in X11 either, though I didn't read the linked issue for what exactly is broken there.
Multi-screen situations is another place where this comes up, which includes not just multi-monitor desktop setups but things like foldable devices, and it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen) and have it available regardless of the compositor the user is using.
One way this can work is: When the program starts up on first install with a brand new config, all those palettes are part of the program window. Then as the user decides to undock them one by one, they are removed from the main program window and a new window is drawn containing that palette. So the user isn't presented with "a ton of palettes"; they get them one at a time and can move them as they wish.
The rest of that (maintaining their position next to the main window, restoring them when the application is restarted) would be solved by a protocol that allowed relative positioning, which was already suggested in the wayland-protocols MR discussion.
>it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen)
This can already work today if the compositor provides a way to do it, as long as the application tags such a window with some unique `app_id` or `title`. For example in sway the user can write config rules to match windows based on such criteria and run position etc commands on them. I assume KDE also has something like this because I remember it having a way to match windows using X properties in the KDE 4 days.
Kind of a real FU way of trying to move things forward...
What if the program doesn't want a single-window mode?
Or what if the work to support a single-window mode isn't considered to be worth it when the only people who care are the 0.01% of users who are on Linux and care that the program isn't Wayland-native?
What you're describing is what happens in most desktop environments any time you open multiple document windows at once. Why is it so much more unacceptable for this to happen to tool palette windows? Yeah, it's obviously not good behavior, but it's prevalent enough that it's clearly a manageable problem for end users and generally preferable to refusing to support multiple windows at all.