Failure seems unrelated.

I am wondering if one should replace one of the legends (or possibly add one in the middle) that uses the rcParams?

Regarding the 0/1 issue, I'll add that to the agenda for the dev call tomorrow.

Oh, and if you know how to rebase and squash, please do that.

It would also make sense to edit the commit message and add the line (after two empty lines):

Co-authored-by: Tranquilled (or proper name)  <whatever the email is>

I don't know how to rebase and squash, but I can probably figure it out. And add the coauthor message too.

Are there any updates on the 0/1 issue that warrants changing the code here?

@tuncbkose we have instructions for squashing here:
https://matplotlib.org/devdocs/devel/development_workflow.html#rewriting-commit-history

Thank you for your work on this @tuncbkose however I'm going to push this to 3.8. There are a couple of outstanding questions that will take too long to sort out to sneak this in for 3.7.

• Should we make the input bool or dict as Shadow will take all of the Patch keyword arguments. As @timhoffm points out if we start making it possible to thread the color through it is likely there will soon be a demand for threading through the rest of the parameters. This then leads to the question of how to handle the rcparams as we do not currently have any structured values (there is no validate_dict) so either we would have to add that (which would be a lot of work) or accept that there are values you can pass at run time that can not be set in rcparams. Neither are great options.
• Another option would be to add a shadow_props kwarg. The upside of this is we side-step all of the rcparams issues (at least for a bit), but the major down side is now we have coupled kwargs (where the value of one kwarg affects if we even pay attention to the other). It would not be the first place we have this, but they are messy to document and use (but sometimes you need them for "Do What I Mean").
• @timhoffm and I need to sort out what to do about the {0, 1} cases (this is the second or third one to come up recently). On one hand I agree with Tim that the using 0 and 1 literals is place of True and False is not good, but on the other hand I am still very wary of ripping out the duck-typing (but not ideas I would endorse) with no warning.

While this seems like a very small change (and the actually implementation is straight forward), there are a bunch of follow-on consequences. Some of the more gnarly parts of the Matplotlib API are due to adding features that were relatively small but eventually began to interact in surprising ways!

I think my favorite path forward is:

• make the shadow kwarg to be None | bool | dict
• if setting the color via rcparams is a hard requirement add at legend.shadow_props.color entry (so we have space to add more if needed)

I think something like:

if shadow is None:
    self.shadow = rcparams['legend.shadow']
    self._shadow_props = {}
elif instance(shadow, dict):
    self._shadow_props = shadow
    self.shadow = bool(shadow)
else:
    self.shadow = bool(shadow)
    self._shadow_props = {}

# maybe
for k in ['color']:
    self._shadow_props.setdefault(k, rcparams[f'legend.shadow_props.{k}'])

...

if self.shadow:
    Shadow(self.legendPatch, 2, -2, **self._shadow_props).draw(renderer)

This:

• side-steps the "how much duck type preservation" by preserving the existing behavior at the cost of deciding the ambiguity of shadow={} should mean in terms of "bool like" not "props like"
• lets the user control the shadow color at the call sight
• also takes care of any future "but what about the " issues now
• gives an (optional) path to setting a subset of the properties via rcparams independently of setting if the shadow is shown by default or not

The biggest down side is a further growth of the number of rcparams, but I think that is marginally less bad than the existing rcparams getting more complex.

My last comment is the summary of a phone discussion with @QuLogic and @ksunden .