Most of this is much too loud for a newbie who is about to read PEP 7 anyway.  And if this community has chosen to try (?!?) not to break compatibility with code which does not have a notion of a locale setting (i.e. naively uses other code in that spirit), you know, then this is simply the way it is.  Thus: you're right.  I do agree with what you say, we here have a (8-bit) C++ library which does this in it's setup():

        // Initialize those Locale variables we're responsible for
        Locale::_ctype_cclass = Locale::_posix_cclass;
        Locale::_ctype_ccase = Locale::_posix_ccase;

(Like i said: we here went completely grazy and avoid system libraries whenever possible and at least directly, doing the stuff ourselfs and only with syscalls.)

Besides that i would agree with me that unthreaded init, optional embeddor locale argument, cleanup of .getprefer...() and other drops of setlocale() are/would be good design decisions.  And of course: "keeping the thing simple and understandable" is a thing to keep in mind in respect to a normal user.

After the end (i have to excuse myself once again for a book):
I, f.e., opened an issue 11059 on saturday because the HG repo was (2.7 may still be) not cloneable, and i did so at selenic, too.  Notes on that:
- pitrou closed it because this tracker is of course for Python bugs.   (I asked him to decide - thanks.)
- The selenic people told me that i added my trace to a completely wrong issue.  (Just searched - that's more than shown in trace dump.)
- I've found out that many, *many* issues seem to have been created due to this repo failure at python.org (at selenic), and i've added a note that they possibly should include a prominent notice that people should look for "most recent call last" before creating a new one.  (I guess that most of these people are programmers - who else uses HG?)
- Conclusion: maybe even os.environ[]= == locale.setlocale() is not simple minded enough.