The PYTHONHOME variable does not allow complete control over making a
Python installation find its own libs because "lib/pythonX.Y" gets
appended to it, see:
    http://docs.python.org/using/cmdline.html#envvar-PYTHONHOME

For example, let's say my Python installation is here:
    /home/soundmurderer/lib/x86_64/python2.6

I cannot set PYTHONHOME to point to this, because my path does not end
in "lib/pythonX.Y".  Of course, you could say that I should just move
the Python libs, but it may create inconsistencies on how stuff is
organized on some systems.  PYTHONHOME should point to the Python
installation root, period.  Please give the admin complete control.

Also, the --libdir flag to ./configure should work and set PYTHONHOME
correctly.  The fact that it does nothing has its own ticket, see:
    http://bugs.python.org/issue858809

It is, however, my humble opinion that fixing that other ticket properly
also necessitates fixing how PYTHONHOME works (because --libdir should
set the default PYTHONHOME during build/install), so they should really
be one issue.

Thanks!

PYTHONHOME is defined as 'prefix:exec-prefix'.  Given that definition
the library must be resolved relatively by appending 'lib/pythonX.Y'. 
Given the long standing nature of this interface, I doubt the meaning
can be changed.

It might be possible to _extend_ the definition of PYTHONHOME to have
additional elements, one of which would be libdir.  It seems to me that
this would be backward compatible.  This possibility, and/or other
solutions, would be more appropriately discussed on python-ideas.  And
then of course someone would have to develop a patch to implement
whatever scheme wins consensus (assuming the consensus is that this is a
problem worth solving).

> PYTHONHOME should point to the Python installation root, period.

And indeed, it does. After your proposed, changed, it wouldn't anymore.
The Python installation root is *not* the directory where the Python
library lives, but the parent directory in which both to find the python
executable (bin/python), and the library (lib/pythonX.Y).

As R. David Murray explains, there is no chance that this definition
could possibly change - it would break existing systems.

I'm not quite sure what you want to achieve: if you want an additional
directory to show up in sys.path, just edit Modules/Setup.

OK, I'm convinced.  Changing PYTHONHOME is bad.  But I am all in favor
R. David Murray's solution of extending to include something like
PYTHONHOMELIB.

Martin v. Löwis: What I want is simply to be able to use --libdir to
tell ./configure where to put standard Python libs, and I want my Python
installation to recognize this lib location without having to hack
PYTHONPATH or PYTHONHOME or anything else.

This would make the behavior of --libdir exactly what people generally
expect from using configure scripts supplied by many other projects.  As
of now, setting --libdir doesn't even do anything, silently!  But even
fixing --libdir per patch in http://bugs.python.org/issue858809 still
doesn't work because the lib path has a hardcoded component.

I just think that a sys admin, when he/she sees a configure script,
should be able to tell it what to do via flags, run it, and expect it to
Do The Right Thing, without worrying about the Python-specific
workarounds to make libs and bins go to the desired place.

> Martin v. Löwis: What I want is simply to be able to use --libdir to
> tell ./configure where to put standard Python libs, and I want my Python
> installation to recognize this lib location without having to hack
> PYTHONPATH or PYTHONHOME or anything else.

Ok. Then I shall close this report as "won't fix", because
a) we cannot change the semantics of the environment variables easily,
   and
b) changing environment variables doesn't solve your original problem.