I was thinking of reviving the linked PR, but I saw something that confused me a bit.
In a code like ax.legend(shadow="y") should "y" be interpreted as "yellow" or True (as in yes)?

More generally, in test_rcparams.py, there are some expressions (under validate_bool) that presumably should be accepted as booleans:

('t', 'y', 'yes', 'on', 'true', '1', 1, True)
('f', 'n', 'no', 'off', 'false', '0', 0, False)

Is there a principled way to check if a shadow argument is one of these beyond just copy-pasting the tuple? Or is something like

if is_color_like(shadow):
    ...
elif shadow in ('t', 'y', 'yes', 'on', 'true', '1', 1, True):
    ...
elif shadow in ('f', 'n', 'no', 'off', 'false', '0', 0, False):
    pass
else:
    raise ValueError('shadow must be a valid color or bool')

good enough?

I believe that one should differentiate between the rcparams and passing the argument to legend.

For rcparams there will indeed be a bit of a clash for 'y' and, I think, 1 and 0. Can be worthwhile noting this in the docs.

For legend=..., only True/False are valid, so there it shouldn't be a problem.

I think the current code deals with it quite OK, but one should probably document the possible clashes somewhere and how it behaves.

I think deprecating the interpretation of t/f/y/n as bools in rcparams would be reasonable too.

is this issue still open? If yes I would like take it.......

There is already some work done and discussion in the linked pull request. I was hoping to finish it next week but feel free to help if you'd like.