Are you sure 1e-6 is a universal solution? Caneventpress.xdata not become -1e-6?

Maybe better to

xdata_press = eventpress.xdata if eventpress.xdata != 0 else 1-e6refx = event.xdata / xdata_press

I think we should give a reason for these somewhat particular limits. Please add a sentence:

The range limits are currently dictated by the implementation.

or similar.

One a side note: Shouldn't it be possible to cover the range -45°...45°, at least there the corner order does not change. One only has to add a sign, which may be possible to infer from the mouse vs start_point location. But this does not have to be in this PR. It's already very big and almost ready to go in.

Good idea, I change to -45 to 45 because it is a easy change!

That would be great as it allowed at least to cover the entire range of orientations with some axis tricks!
Could you also add a note what specially was not working with larger angles, so this might be considered in a follow-up as discussed in#20839 (comment)?
In particular, did the problems occur only with specific backends? As I mentioned, I did not notice any serious problems with up to 90 (and in fact now tested up to ±180˚, which effectively allows any number of full rotations). The only obvious issue was, on subsequent resizing of the rotated rectangle, the centre seems to start moving on some kind of trochoid, but whole weird-looking behaviour on resize can of course be avoided by clicking to'center' state.

Could you also add a note what specially was not working with larger angles, so this might be considered in a follow-up as discussed in#20839 (comment)?

I don't remember but I would expect the value ofself._active_handle to be incorrect when rotated more than -+45, e.g.'W is picked while it should be aS, etc.

The only obvious issue was, on subsequent resizing of the rotated rectangle, the centre seems to start moving on some kind of trochoid, but whole weird-looking behaviour on resize can of course be avoided by clicking to 'center' state.

I have noticed it recently and I think this is related to_get_aspect_ratio and it would be good to improve it in another PR.

I don't remember but I would expect the value of self._active_handle to be incorrect when rotated more than -+45, e.g. 'W is picked while it should be a S, etc.

Thanks; this will be a very useful starting point! Yes, I would expect that the point originally labelledSW could end up somewhere on theE side etc., but could not figure out where that would cause trouble. Any other hints what to watch out for with a follow-up are definitely appreciated.

The motion I think is inevitably somewhat confusing as the fix point for resizing is not rotated along with the bounding box, but that seems quite tricky to address. It is certainly recommendable to use'center' mode for resizing of the rotated shapes.