The issue here is not unique to OS X. I see the same behavior on Linux with a built-from-source Python 3.2a3 and Distribute 0.6.14. (As I noted earlier, Debian and presumably various other distributors package a patched version of setuptools / Distribute which does not do the "bootstrap" manipulations so you likely wouldn't see the problem.)

importlib.import_module('site') finds the standard library version whether s/D is installed or not.  But that is to be expected.  This problem is unique to the site module because the path manipulation stuff happens first and in the normal environment (not -m), sys.modules['site'] will always be pointing to the standard lib version; the s/D bootstrap erases its tracks so to speak.

Just to be clear, I don't think there is any Python problem here.  It's all due to how s/D tries to manage import order.  The only way around it is for s/D to recognize and support the -m site case.

Here's what is in easy_install.pth, with my {} annotations:

import sys; sys.__plen = len(sys.path)
{... an entry for the first easy_installed distribution ... }
./appscript-0.21.1-py2.7-macosx-10.3-fat.egg
{... and entries here for any other easy_installed distributions ...}
{... ending with this last one for distribute or setuptools itself ...}
./distribute-0.6.8-py2.7.egg
[ ... which creates the _egginsert attribute used here }
import sys; new=sys.path[_sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; s
ys.__egginsert = p+len(new)

The distribute egg contains a site.py at the top level.  If you are interested in looking at it, it's probably best to just install distribute and look at what happens in site-packages.