> Adding a separate build step for SWIG (then the order would be build_swig, build_py, build_ext) would be safer and IMHO also more logical.

I like this suggestion and contemplated it. However SWIG interface files are defined in Extension instances, which are inherently tight to the build_ext command. Breaking this link would require introspection of extensions before deciding on which command to invoke, or a completely separate SWIG Extension class, both of which require a change in usage.

> It's not uncommon for projects to extend distutils in various ways and the proposed change may break those packages.

I argue that those packages are already tempering with default behavior of distutils, while the change I am proposing is fixing a flaw in basic functionality and might I say 'implied behavior' of distutils (as the docs say distutils understands SWIG, while it isn't currently even capable of installing correctly when SWIG files are used).

The build_ext and build_py commands are truly separate commands, except when SWIG interface files are used:

- build_py is responsible for copying pure python files to their correct directories, potentially compiling them to .pyc files.

- build_ext is responsible for compiling and linking C/C++ files and copying resultant files to their correct directories. It is only when SWIG files are supplied that a .py file is produced, which quite neatly would be picked up by build_py, given the chance.