Does this play nice with scatter(), which already has a c parameter?

I guess scatter will just eat up the c argument by itself instead of passing it down to the alias machinery? Mentioned that in the changelog note.

My question is also: Did you check that the newly introduced API for whatever(c=...) is conceptually similar to scatter(c=...), e.g. in terms of accepted values, broadcasting, precedence color/facecolor etc.? It would be unfortunate to have functions with the same semantic and syntactic parameter c that would have an unnecessarily different API. It may be ok for some functions to have a narrower API, e.g. no broadcasting or not supporting multiple values (even though that should be synchronized).

fair point, needs checking

though likely #12021 will need to be resolved first to clean up the tangled mess

Actually, it's clear that this cannot be consistent in the case of scatter because scatter's c argument can be colormapped whereas color cannot:

scatter([1, 2], [3, 4], color=[0, 1])

results in

ValueError: 'color' kwarg must be an mpl color spec or sequence of color specs.
For a sequence of values to be color-mapped, use the 'c' argument instead.

(the colormapped attribute is array, not color).

Any change would probably require more surgery, so I'll just close this for now.