Window bounds: y origin changes meaning from read to write

Hi, apologies if I failed to find a previous discussion on this.

In InDesign/InCopy CS (I tried CS5.5) the following self-assignment effectively results in no change, as you might expect:

app.windows[0].bounds = app.windows[0].bounds

or in AppleScript:

set bounds of window 1 to bounds of window 1

Specifically, no matter whether I'm getting it or setting it, app.windows[0].bounds[0] (or in AppleScript "item 1 of bounds of window 1") means the distance from the top of the screen to the top of the frontmost app window. So, reading bounds[0] and then writing the same value back to bounds[0] means I end up with unchanged coordinates. All good.

But in InCopy/InDesign CC 2018, reading the bounds and then writing the same values back will cause my windows to move.

This appears to be because in CC 2018, the value returned for bounds[0] seems to have changed. It's now giving me the distance from the bottom of the screen to the bottom of the window. OK, such is progress. But, perversely, when I write back to the window bounds, the value I provide for bounds[0] gets used in the same way as in CS: it sets the distance from the top of the screen to the top of the frontmost window.

So InDesign/InCopy seem to be using two different ways of describing a rectangle for the same property, depending on whether you're reading it or writing to it. Or am I being unfair/doing something terribly stupid?

I'm prepared to normalise the y origin value in the scripts that I'm porting to CC. But if this is actually a bug rather than my stupidity, then I probably shouldn't assume that the behaviour isn't suddenly going to change. If it did change then potentially my normalisation could do end up doing more harm than good. In which case I should probably step outside the app and handle the windows via the operating system.

Tried on MacOS 10.10, 10.11, 10.13 using InDesign and InCopy CC 2018 (specifically v13.1.0.76).