but fixing the
machinery to allow 15° while rejecting 150° would be trickier.

That would best be done with a new type of locator. Something like aChoiceLocator that can only select from given sets of values.

I know, I was just hoping that this PR can be considered a stepwise improvement and defer ChoiceLocator to later (well, it's more complicated that ChoiceLocator, it's really "below a given scale, behave as MaxNLocator, above it limit yourself to some fixed values").

I guess I think if we are changing the API, it should be done at once?

This PR

Im ok with an incremental improvement. I doubt that anybody relies on the current behavior as something they explicitly want. In particular, the second time changing would only affect the very right example. If somebody is ok with 100°, it means they don't realy care, and 150° and later 90° should be fine for them.

If we don't want to invest addtional time in this now it's ok to get the more common cases right at the potential cost of changing an edge-case twice.

Alternative idea

The theta-scale is much simpler than other scales, because it's finite and we can thus hard-wire all reasonable solutions.

Maybe I'm underestimating this, but I would have assumed that we can define

ChoiceLocator([    [0, 30, 60, 90, 120, 150, 180, 210, 240, 270, 300, 330],    [0, 45, 90, 135, 180, 225, 270, 315],    [0, 60, 120, 180, 240, 300],    [0, 90, 180, 270],])

which can choose one of the given lists to draw tick locations from. Your first plot would choose the first list, the second may choose the second list, and the third might choose the fourth list. The only thing I'm not sure about how is how the locator knows about the available space and can thus choose more or less values, but apparently the current locator does that already, so it should be possible.

re: the alternative idea:

1. The locator knows the available space viaAxis.get_tick_space... which actually likely needs a reimplementation both for theta and r (see e.g. the overlaps in the r ticks for the small axes), but that's a separate issue.
2. The problem would be for thin slivers (plotted on really large axes), e.g. from 0° to 10°, where you do want to fall back to the "normal" (MaxNLocator) approach. Again, that's certainly fixable, just needs a bit more work thanjust setting the steps on the current MaxNLocator...

The problem would be for thin slivers (plotted on really large axes)

You could label only the two edges in this case, which can be a fallback for aboveChoiceLocator if the theta-range is too small. That should begood enough for a default. IMHO this is really an edge-edge case*, and we don't have to over-think it.

*I tried to find such a plot on google, but didn't manage to.

Fair point, but let's move this to another time? A new locator class means new tests to be written, too :)

I opened#20025 to separately track further improvements.