Logged In: YES 
user_id=21627

_Py_ReleaseInternedStrings: it might be that embedded
applications use it. It would not be fair to cause heap
corruption for them - it would be better to break them at
link time, by removing the function entirely. I see no need
to do either - it should just release immortal strings, as
it always did, if there are any left.

intern creates immortal strings: It might be that an
application saves the id() of an interned string and
releases the interned strings; then expects to get the same
id back later. If you ask people whether they do that they
won't tell, because they don't know that they do that. You
could explicitly decide to break such applications (which
would be reasonable), but then this needs to be documented.

binary compatibility: I'm neutral here. If the API is
bumped, people get sufficient warning.

PyString_InternInPlace: I think it needs to be preserved,
since applications may not hold explicit references
(trusting that the interned dictionary will hold the
reference). Of course, the InPlace name signals that there 
is no return value, so it is better than _Intern for new users.