I'd expect both bbox and coords to return coords in the same frame of reference in which an item was drawn. In the example above, I'd expect:

# after rotate 90°
% .c coords test
20.0 20.0 50.0 30.0
% .c bbox test
17 17 53 33

TL;DR

Imagine doing land surveys on (the rotating) Earth using GPS coordinates, but when it came to the bbox of the area you'd just measured, finding your instrument returned coords in the frame of reference of the Sun.

When rotating the root of the canvas, the whole frame of reference (FoR) of the canvas is rotated. Transformations specified for item 0 with -matrix [tkp matrix ...] are applied to the FoR of the root and not to the individual items or their bboxes. From the standpoint of an individual item, its coords, transformations and bbox should all be in the same FoR.

The way it stands now, bbox seems to refer to a different FoR (that of a 'universal' observer?) than do the coords. Bbox's FoR cannot have any items drawn with it, because the items are instead drawn on the canvas root. If I were to describe in tk's parlance the behavior of coords and bbox, using the Earth-Sun example above, that would be:

.c create prect 10 10 60 30 -tags coords_on_Earth
.c bbox -ref Sun coords_on_Earth

If one tries to draw items using the coords reported by _bbox_ of a transformed canvas root, e.g. [.c create prect 167 16 183 52] using the coords returned by bbox in the rotated example in my first message above, he'll find that the items end up drawn _not_ where they are expected in the FoR of _bbox_ (the 'universal' observer?). This is because the items are actually  drawn on the transformed canvas root and _not_ on the imaginary fixed FoR of bbox. The FoR of bbox lacks a physical 1:1 representation on the canvas. Tk's canvas escapes this problem by having just one FoR and by not being capable of doing transformations.

There may be some other conceptual discrepancies too: gradients use a 'bbox' in the definition of linear transition units; that 'bbox' retains the same orientation with the orientation of the (transformable) items where said gradient is used. This is the expected behavior, but it is different from the way [.c bbox items] behaves.

So again, I'd expect bbox to return the same coords in the rotated root FoR as it does in the un-rotated one, because the frame of reference in which the items are drawn has _not_ changed _for the items_. This, seems to me, would be the only way bbox can have some practical use when drawing on a transformable canvas.

Generally speaking, I'd expect default [.c coords items] and [.c bbox items] to return coords in the frame of reference defined by their ancestor(s). This is how -matrix behaves today, but not how coords and bbox behave. An general optional case could be made for returning coords or bbox in a different FoR, with something like:

.c coords -ref otherFrame tagOrId
  and
.c bbox -ref otherFrame tagOrId

Hopefully the above make sense.