Let's the name markerprops. This is a bit different from SpanSelector. First, here we have lineprops + 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 between lineprops and markerprops, I will need to look it up.

In 35ee92d, I have changed the various patch properties (rectprops, lineprops) argument to props, so that now we have only props and handleprops 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 using set_props or set_handle_props, we could set the properties regardless of what type of object they are.

I am happy to revert 35ee92d 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 between lineprops and markerprops, I will need to look it up.

Conversely, I argue that props is even less helpful. The different selectors are realized by different Artists and thus have different properties. We cannot hide that fact. SpanSelector accepts facecolor, LassoSelector accepts solid_linestyle, and neither accepts the other one respectively. With props 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 that EllipseSelector inherits from RectangleSelector.

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 by ellipse or selector to fix this issue.

I even claim it's a mistake that EllipseSelector inherits from RectangleSelector.

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