Antoine does seem sold on the 100% branch coverage requirement and views it as pointless. I disagree. =)

As for the exception Stefan is saying may be granted, that is not in the PEP so I consider it unimportant. If we really feel the desire to grant an exception we can (since we can break any of our own rules that we collectively choose to), but I'm assuming we won't.
 

Raymond thinks that have a testing requirement conflates having implementations match vs. APIs. Well, as we all know, the stdlib ends up having its implementation details relied upon constantly by people whether they mean to or not,  so making sure that this is properly tested helps deal with this known reality.

This is a damned-if-you-do-damned-if-you-don't situation. The first draft of this PEP said to be "semantically equivalent w/ divergence where technically required", but I got pushback from being too wishy-washy w/ lack of concrete details. So I introduce a concrete metric that some are accusing of being inaccurate for the goals of the PEP. I'm screwed or I'm screwed. =) So I am choosing to go with the one that has a side benefit of also increasing test coverage.

Now if people would actually support simply not accepting any more C modules into the Python stdlib (this does not apply to CPython's stdlib), then I'm all for that. I only went with the "accelerator modules are okay" route to help get acceptance for the PEP. But if people are willing to go down a more stringent route and say that any module which uses new C code is considered CPython-specific and thus any acceptance of such modules will be damn hard to accomplish as it will marginalize the value of the code, that's fine by me.