I'm just trying to understand why ImGui needs to read and write window positions, because it's not immediately obvious from that paltry description. It sounds like you're describing a use case where it needs to be able to set the position of a new window relative to an existing window. So APIs to read the position of the current window and write the position of the new window are probably what they're looking for—though I can readily imagine narrower APIs to handle that use case. Does that sound to you like an accurate explanation of their complaint?
(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.)