It seems overly inconsistent to be able to read but not write bad_color etc, since writing is mostly what one wants to do from user code.  For the purpose of your function, you don't need an external API--you could just use the private variables.

The rationale for keeping set_bad etc. would be that they include the alpha kwarg, although that is never really needed; one could always use, for example, ```bad_color = mpl.colors.colorConverter.to_rgba("r", alpha=0.5)```.

The use of setters and getters is a legacy.  There are places where they serve a major function in the auto documentation system, but here in the colors module the are just fossils from early days.  (I put them in.)  I don't see any urgency to deprecate them, but I think that using them to flesh out the bad_color etc. properties would make sense, if you really want to proceed with bad_color--which I think makes for a much nicer API.

This brings up another point: to_rgba and friends are so deeply hidden that even I can never remember how to access them, but have to hunt around to find them.  (A camelCase name?  How did we end up with that?) Wouldn't it be nice, from the user standpoint, to have basic functionality like this in some more obvious place--either directly in colors as a function, or maybe even the base matplotlib namespace?  Right now, that namespace (from ```import matplotlib```) is full of completely useless junk--throwaways from the startup process.  Ugly!