I didn't know what was possible when I wrote PEP 432 either - instead, I wrote down an initial concept for what I *wanted*, and then started exploring the code to find out the barriers to achieving that.

We know enough now to know that original design concept isn't technically feasible, but that's OK - the general idea was just to get to a point where the startup code is better tested, easier to maintain, and easier to control in an embedding application, and everything outside that is negotiable.

The problem with the purely bottom-up approach is that we may end up with something that's better tested and easier to maintain, but find out that it hasn't actually helped us get to a point where we can make the interpreter easier for embedding applications to manage.

As far as Unicode goes, it isn't Unicode as a concept that's problematic, it's specifically the CPython Unicode type: that needs hash randomisation configured, and that means we need to have already processed the input settings that can affect the hash seed. And unlike UTF-8 mode, where there's a comparatively limited set of strings to recreate with a different decoding step, there's no escape hatch to let you cleanly recreate all previously created string objects with a different basis for their hash.