Summary

Following up on #26406 (comment)

rcParams should be only configuration, not state; i.e. wrt. backend, it can hold the desired backend and backend priorities, but it should not hold the currently active backend or trigger backend selection as a side-effect. The latter causes a lot of complexity in rcParams, which is responsible for the failed attempt to deprecate rcParams._get("backend") (#30963) as a lot of internal logic depends on it.

Proposed fix

We should remove backend state handling from rcParams. Due to the internal complexity and API that is used both internally and public, the migration is complicated. I propose a multi-step approach:

• (1) Make the backend a RcParams class attribute and do not hold "backend" as a regular dict entry. There can only be one backend, so putting that value in a class attribute RcParams._backend makes sense. This already reduces the complexity as we don't need special handling to sync/copy the value when rcParams are bulk-replaced (loading from file or rc_context). Instead add special logic to keep behavioral backward compatibility with the dict API (rcParams["backend"] / rcParams._get("backend"), "rcParams._set("backend", val)).
  MNT: Move "backend" from a regular rcParams dict entry to a class attribute #31792
• (2) Move all internal backend logic to not go through the official rcParams dict API anymore.
• (3) Deprecate the rcParams dict API for "backend"; if needed add more
• (4) Move the backend state from RcParams._backend away from RcParams, and either into pyplot or into top-level matplotlib. - Possibly only after the deprecation has expired.

The motivation is that deprecation (3) is very difficult (see #30963) as long as we use the API internally, so we first need to change our internal usage (2), which requires a state that is easily accessible without the dict API (1).