I think the idea makes sense, but find the proposed name potentially confusing for two reasons:

1. It isn't only about configuration, it's about interpreter initialisation state in general
2. We use "context" for several other purposes already (most notably with statement context managers and async contexts)

Given the proposed "_PyPreConfig" construct, how would you feel about calling this "_PyPreInitState"? The idea there being that like PreConfig, the PreInitState would be discarded once the interpreter was fully initialised - the PreInitState would only be needed to handle cleanup *while* initialising (either of temporary values, or in the event of initialisation failing and needing to undo previous allocations).

My comment from #32566 also applies here: PEP 432 is now lagging so far behind the state of the private API implementation that it really needs an update to better reflect where you're wanting to take the public initialisation API following these changes.