Here are reasons why PyConfig relates to the runtime and not each interpreter:

* PyConfig was introduced so embedders could dictate how the *runtime*
  should be initialized
* after initialization, it represents how the runtime was initialized
* in the public API, PyConfig relates only to the runtime
* more than a few PyConfig fields are specific to the entire runtime
  and not appropriate on a per-interpreter basis
* such PyConfig fields are only used during runtime init
* currently, every interpreter uses (a copy of) the original PyConfig,
  completely unchanged
* there is no API for creating an interpreter with a different config
* most of the things that one might want to customize on an interpreter
  can already be done right after the interpreter is initialized
* thus far we have had no actual use cases for initializing an interpreter
  with a different config
* for many of the PyConfig fields, allowing different values for each
  interpreter is an attractive nuisance and would invite confusion

This is why PyConfig makes more sense as the global config, not a per-interpreter one.  I think it was a mistake to store the config on PyInterpreterState.  Keep in mind, though, that PyConfig was added several years before _PyRuntimeState existed.  If _PyRuntimeState had been around, I'm sure that's where we would have kept the global config.

Thus, it makes sense to move PyInterpreterState.config to _PyRuntimeState.config.  If there's a need for a per-interpreter config later, we would do the following:

* add a new PyInterpreterConfig with only the fields we need
* add a new PyInterpreterState.config field of that type

In fact, that is exactly what I'm proposing in PEP 684, where there is a need for creating an interpreter with various isolation options.  That's what got me thinking about why PyConfig isn't good for customizing new interpreters.  Even if we didn't move PyInterpreterState.config to _PyRuntimeState.config, PEP 684 would still not use PyConfig as the config to pass when creating a new interpreter.  Using PyConfig would be confusing and an invitation for trouble.  So I'd use a new PyInterpreterConfig either way.  Consequently, having PyConfig on PyInterpreterState would be confusing, with no benefit.

My intention with this BPO issue was to get our internal details aligned with what makes sense for a global config and set the stage for adding a proper per-interpreter config.