In order to fix this, either the parent axes must be forced to be equal-aspect

I don't think you should enforce an equal aspect of the Axes box. This would lead to scaling the height of the box when you change the width of the figure. This (i) not how GUI elements normally behave and (ii) can lead to vertical shrinking and thus vertical text overlap.

If you play the aspect game, I think it would need to be in data coordinates. - But that means, changing Circle and Text coords to data, which is technically a breaking change as well.

or abuse scatter()

Using markers may actually be a good idea because they are in (i think) points, so that they have a constant size just as the Text.

Either way, if compatibility is a concern, it may be a reasonable approach to create a new RadioButtonGroup widget and discourage (/deprecate?) RadioButtons.

This would lead to scaling the height of the box when you change the width of the figure.

I think(?) you can prevent this with set_adjustable("datalim")?

This would lead to scaling the height of the box when you change the width of the figure.

I think(?) you can prevent this with set_adjustable("datalim")?

This will only affect the circle if you switch to specifying the circle in data coordinates. As long as the circle stays in axes coordinates, the datalims will happily scale beneath it without any visual effect.

Do the sliders change aspect when the figure is changed? These should be in figure physical units (points) shouldn't they?

Sliders cover an entire axes, so it comes down to how you specified the axes? But most likely (whether it's an add_subplot() or an add_axes()) they will indeed change aspect in that case.
Unless you're talking about the round "button" of the slider; that one stays circular, because it's actually drawn with plot(..., "o") (which is a more or less similar strategy to drawing with scatter -- for radiobuttons, the advantage of scatter is that it would easily allow one button to be selected and not the others, while keeping everything within a single artist).

Note that the same issue also affects CheckButtons, and from a quick try one can use a solution similar to #24455 (using two series of scatters, one with marker="s" and the other with marker="x", with the color varying on the latter); it may be a good idea to make that a good first issue once #24455 is merged, suggesting to take that PR as example of how to fix it.

and the other with marker="x"

Or maybe somebody want's to create a fancy CheckMarker class for this ☑️ 😀