Why are we adding an alias to keywords?
We should have one and only one way to do things, and if possible give explicit names to arguments and variables. I'm not convince it's a good idea to add more aliases than we already have (I think we should be deprecating those in fact).

I'm 👎 on the ds alias and 👍 on the rest.

@NelleV I understand your argument against aliases, and have been on the same page. However, when working interactively a lot, I've come to appreciate, being able to write ls instead of linestyle. OTOH, the drawstyle is likely rare enough that an alias is not really neccessary.

So -0.5 on ds, but +1 on keeping existing aliases.

I’m good w the alias. Even if you script, not typing “linestyle” each time would be a nice convenience.

Whether we should fully get rid of aliases is a good question (I agree with @jklymak that they have their usefulness) but I think it's better to be consistent and provide aliases for everything for now rather than have an inconsistent alias system. Adding ds=drawstyle is not going to make the whole alias system harder to deprecate if we really choose to go that route.
If you want to get rid of "having multiple ways to do the same thing", I'd rather first get rid of layered APIs as suggested in #11691, which are much more harmful than straight aliases IMO...

👍 on the separation of drawstyle and linestyle/other params. I don't know how often a construct like "steps--" is currently used; so a long enough deprecation period makes sense. Is removal == since +0.2 always?

I don't have a strong opinion on the alias.

I was wondering if it would be good to add tests for deprecations like this? I.e. a test that the intended use case (linestyle="--", drawstyle="steps") works fine (such test might exist already?) and a test that the still supported, but deprecated case throws a warning. At the end of the deprecation this should then test if the correct error is thrown. This way you would ensure not allow for this kind of mini-language API to be reintroduced in a couple of years.

This way you would ensure not allow for this kind of mini-language API to be reintroduced in a couple of years.

I don't think any of the current maintainers would allow such a thing to pass review.

Our test suite is already huge enough that I wouldn't bother (there are better parts where to improve the coverage, and that doesn't necessarily mean strict numerical improvements, but rather combos of kwargs which don't work well together, see e.g. the discussion on hist/align...).