In case it isn't clear from the discussion in issue8792: I'd be in favor of supporting extensions as long as their usage is an opt-in feature. The current nil support is already an opt-in feature. If alternative spellings of nil need to be supported, or other extensions, it might be necessary to refactor this extension support a bit, so that extensions can be independently be developed and activated.

As for Python's usage of nil: it is specified in

http://ontosys.com/xml-rpc/extensions.php

and also referenced in the Wikipedia. IMO, it would have been better if Apache had used the pre-existing extension, instead of coming up with its own (supposedly only because the pre-existing one wasn't namespace-based).