Let's the namemarkerprops. This is a bit different fromSpanSelector. First, here we havelineprops +markerprops, keeping this consistent within the class is more important than consistency with another class. Second, while semantically we have handles in both classes, they are realized by markers and lines respectively and thus accept different parameters. I favor making this clear from the name.

I see what you what you mean, but I am convinced that simplifying the API and making it more generic is worth it at the cost of the being slightly less precise. I agree that using a more specific terminology is more explicit but at the end of the day, when we create a selector - regardless of what selector it is - what we want is to set the properties of the patch and/or the handle, regardless of what their are or of their implementation details.
For example, as an average matplotlib user, I don't know what are the different parameters betweenlineprops andmarkerprops, I will need to look it up.

In35ee92d, I have changed the various patch properties (rectprops,lineprops) argument toprops, so that now we have onlyprops andhandleprops for all selectors.
To address#20618, we could add two method to set the properties of the selector patch and the handle separately. The idea is that either at initialisation or when usingset_props orset_handle_props, we could set the properties regardless of what type of object they are.

I am happy to revert35ee92d if others also think that this is going in the wrong direction!

For example, as an average matplotlib user, I don't know what are the different parameters betweenlineprops andmarkerprops, I will need to look it up.

Conversely, I argue thatprops is even less helpful. The different selectors are realized by different Artists and thus have different properties. We cannot hide that fact.SpanSelector acceptsfacecolor,LassoSelector acceptssolid_linestyle, and neither accepts the other one respectively. Withprops the user has to lookup what is supported as well. But it's more surpising and harder to remember that the same parameter name accepts different inputs depending on the class.

Why this indirection?

To be able to reuse the docstring in EllipseSelector and RectangleSelector.

I see. I'm not a fan of too much indirection in the docs. Some duplication is ok sometimes.

Reuse implies coupling. The risk with indirection is that people start to write about Rectangle explicitly, which does not make sense for the Ellipse case. Conversly, the risk with duplicated docstrings is that they are not in sync (which IMHO is not the end of the world).
I even claim it's a mistake thatEllipseSelector inherits fromRectangleSelector.

It's a tradeoff which I would decide in favor of the duplication here. But I'm not going to fight over it.

I have put a placeholder for the artist type to be replaced byellipse orselector to fix this issue.

I even claim it's a mistake thatEllipseSelector inherits fromRectangleSelector.

I don't know about that, maybe for another PR! ;)