This argument makes no sense. The feasibility of removing the library does not depend on the severity of the issues found within it. Either it is hard to remove the library, or it is easy. If it's hard to remove, it doesn't get any easier because I discover a fatal flaw.
We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed.
I've actually provided several examples of where the library fails when used in common scenarios, yet your solution involves incremental hacks that don't fix the underlying problems. You write as if you have a vested interest in releasing the library -- why?
I have a vested interest in releasing Python 3.1, and in sticking to decisions that have been made by other committers. I trust these fellow committers, so I defend their decisions.
I personally have no plans for using this library, or any other IP address library (at least not in any application I plan to write soon). At the moment, I'm struggling more with IP address libraries in Perl.
There are other missing features, but again, my concern is not about missing features: it's about a quirky API that conflates concepts in the problem domain, leading to subtle bugs and breaking the principle of least surprise.
I believe the API appears more quirky to you than it actually is, probably because you don't have understood it fully (but I might be wrong with that, and there might be a different reason).