I'm starting to wonder what the problem really is that makes it so Python-specific. If I understood correctly, it's about a couple of files which must be stored using non-Unix line endings, right? (in the PC and PCbuild directories?)
No. It's about files that must, when checked out on Windows, have CRLF endings, and, when checked out on Unix, have LF endings - i.e. all the .py, .c, .h, and .rst files, plus a couple of others which don't require specific treatment.
IOW, it's about the default behavior, and the majority of new files.
These files are hardly modified often and by many people (and even more rarely by non-Windows people), so why not just put a verification hook on the server and let the offending committer repair his mistake manually, if it ever happens? (we can even provide a script to help repairing the EOL mistake, like Tools/reindent.py does for indentation mistakes)
This was Dirkjan's original proposal, and it is the proposal that brings so much heat into the discussion, claiming that it is a problem of minorities (I do understand that you were unaware that "the problem" is really with the many files, not with the few).
In addition, a DVCS brings in another problem dimension: when people push their changes, they have *already* committed them - and perhaps not even they, but a contributor from which they had been pulling changes. The bogus change may have been weeks ago, so the subversion solution (of rejecting the commit to happen) doesn't quite work that well for a DVCS.