Seems like @timhoffm came across this while doing something similar in #12577 (comment)

The defaults should have also STYLE_BLACKLIST parameters.

The logic (iirc) was that anything that was not style should not be changed by the restore-default methods.

Based on @tacaswell's comment on that, it still doesn't make sense because right now they are persisted even though the code seems to be removing them?

I'm kinda confused about what exactly is the goal here.

webagg.port is specifically in the STYLE_BLACKLIST which is explicitly excluded by the documentation for rcdefaults

The dict inheritance makes it confusing, as we don't actually directly implement __delitem__ but I am surprised that clear doesn't clear out everything.

If I call dict.clear(mpl.rcParams) it does clear out everything...

Somehow we are getting delitem and clear from MutableMapping and not actually properly inheriting from dict as was likely intended.

For completeness, here is the STYLE_BLACKLIST:

{
    'webagg.port_retries',
    'figure.raise_window',
    'docstring.hardcopy',
    'backend',
    'backend_fallback',
    'toolbar',
    'figure.max_open_warning',
    'date.epoch',
    'timezone',
    'webagg.port',
    'webagg.open_in_browser',
    'webagg.address',
    'interactive',
    'tk.window_focus',
    'savefig.directory'
}

Yep. I get that the STYLE_BLACKLIST is excluded but if clear() works as it normally would, then that means that webagg.port and any other entry in STYLE_BLACKLIST should not be in there.

I think the reason it gets the MutableMapping is because our inheritance is defined as MutableMapping first and then dict.

Basically, it feels like the "wrong" implementation is working right now?

In general inheriting from dict was a mistake (and that is what #25617 is addressing)

If I do del mpl.rcParams["backend"] I get KeyError (despite the key actually being there)

Yeah, I think that rcdefaults is a no-op currently, which is not intended...

We do not test it at all.

Given that it broke and nobody complained... perhaps that is a sign it should be either deprecated completely or reworked entirely as part of #25617... It perhaps gives some latitude to make changes that might otherwise have warranted a difficult to navigate deprecation dance.

With the chainmap implementation (modulo the sub-dict structures) the documented behavior appears to be something like:

non_style = {k: self[k] for k in STYLE_BLACKLIST}
self.maps = [defaults, non_style]
self.maps.new_child()

(this is from the perspective of self being a ChainMap and defaults being available, but more or less that is I think what the documented behavior is)

And of course, should get a test...

Yeah, I think I'll redo the implementation there to match the documentation more.