> This is a little arbitrary, but seems as sensible a value as any other.
> (Or maybe it would be better to have get_config_var('srcdir') == None
> instead.)

'srcdir' is problematic for any installed build.  Once "make install" has been performed, there is no obligation to keep the original source and build dirs around anymore.  For Pythons installed on other machines via a binary installer, like the python.org OS X ones, some of the paths returned by sysconfig are not meaningful on the installed machine.  For an OS X framework build, the Makefile and friends are copied into a 'config' directory that is created within the installed framework. So, with the patch, the contents of that directory (returned by the patched 'srcdir' value) is:
['Makefile',
 'Setup',
 'Setup.config',
 'Setup.local',
 'config.c',
 'config.c.in',
 'install-sh',
 'libpython3.3.a',
 'libpython3.3.dylib',
 'makesetup',
 'python.o']

Is that a meaningful surrogate for the build 'srcdir'?

Beyond that, I don't understand why the patch behavior depends on whether the srcdir is an absolute path or not.  I often use absolute paths to configure a build.  If not in a build directory, 'srcdir' should always return either the proposed value based on what get_makefile_filename() returns or it should return None.  I don't have a strong opinion at the moment about which.  One factor should be an inspection and running of all of the tests.  A quick grep of Lib/ didn't find many references to 'srcdir'.

One other point: distutils still has its own copy of sysconfig.  Strong consideration should be given to making a similar change there.