extent coordinate spaces other than "screen" are not useful
GetExtents and GetPosition can accept one of 3 coordinate spaces: screen, parent, and window.
Querying screen seems to work reliably. It returns coordinates that actually line up with an element's position on the screen.
However, I could not find a way to reliably calculate a position using either of the other coordinate spaces. In GTK, adding window coordinates to the window position often produces an incorrect result, often it does not account for the presence of a menubar. (On Qt, they don't even have the correct size, but that's a Qt bug.)
By experimentation, object:bounds-changed seems to return coordinates in the "window" space, which unfortunately makes the values from the event useless for calculating the actual bounds. (And, it means I can't get notifications when a window object is moved, because the events are relative to the window itself.)
As a result, I had to resort to polling screen coordinates.
I would suggest specifying the relationship between these coordinate spaces, and which one object:bounds-changed is supposed to return. It should then be possible to have tools that verify these relationships are correct. While that won't make toolkits return useful data overnight, I think it's the first step toward fixing this.