GeezerVison

To bikeshed the name a bit, auto_resolve or force_resolution? "resolve" is not fully obvious to me that this means "should I try to guess the best available back end or not".

I've been thinking on the name a bit. How do we complete the sentence "If no backend has been selected yet, ..."?

• "trigger backend resolution" / "resolve the backend": this is the "resolve" namespace. I feel "auto" and "force" do not add information here - "automatically resolve the backend", "force backend resolution" both basically state "do the resolution", there's nothing "automatic" about it other than it selects what's available, but that's already the resolution, there's also no "force" it's just the operation to be done.
  Maybe the "resolution" terminology is a bit heavy?
• "auto-select a suitable backend": get_backend(auto_select=True)?
• "activate a suitable backend": get_backend(activate=True)?

I like auto_select the best as it also implies that "one was not set, we did not pick, therefor you get back None"

I think "resolve" makes sense here? get_backend means "tell me what backend I'm using". "resolve" means choose one so it is not unresolved. That this is the default behaviour of get_backend is the design decision we are trying to reverse?

That this is the default behaviour of get_backend is the design decision we are trying to reverse?

This is not a complete sentence (or rather 1.5 sentences 😄). Not sure I understand what you're asking, but I'll try to answer anyway. The first goal is to provide a high-level API for "get the current backend, but don't resolve if there is no current backend". One currently has to rely on the semi-public rcParams._get('backend'), but #26406 (comment) plans to get away from handling backend logic in rcParams. Therefore, get_backend(resolve=False) will be the replacement for rcParams._get('backend').
Whether or not the default should eventually change or not is a separate discussion that can be had later. It does not interfere with this PR.

My point was just that "resolve" makes sense as the kwarg.

Still collecting opinions on the parameter name. Prime candidates are resolve and auto_select.

I think the argument against resolve is that unless you know the jargon we use about the auto-select backend, it is not clear what "get the backend, but do not resolve" means, where as "get the backend, but do not run the auto-select logic" is relatively clear.

Thanks @tacaswell that convinces me. While resolve is slightly more concise, auto_select is easier to understand for people without prior knowledge. -> Changed to auto_select.