Ok, so here's what needs to happen to make this work. Note that all of
the following needs to happen at *runtime*, not at the time at which the
.msi is created:

(1) Find all sub-keys of SOFTWARE\Python\PythonCore in the registry.
These are the versions, e.g. 2.5, 2.6, 3.0, etc.

(2) For each version, get the Python installation dir from
SOFTWARE\Python\PythonCore\%(version)s\InstallPath

(3) Populate the ListView table with entries containing these
installation paths, e.g. something like:

    TARGETDIR 1 C:\Python24
    TARGETDIR 2 C:\Python25
    ...

(4) Modify Control/SelectDirectoryDlg so that it uses a ListView (filled
with the above values) instead of a DirectoryCombo.

(5) Make a couple minor edits to bdist_msi.py to stop it from inserting
the version into the .msi name for Python-only modules.

I looked into a couple ways of doing this. Ideally, we should avoid
using a CustomAction, which would require maintaining some additional C
or VBScript code, and instead do everything through the database tables
that are built into all .msi files. Some problems I've run into with
this approach:

* The only way to read the registry AFAICT is through the RegLocator
table: http://msdn.microsoft.com/en-us/library/aa371171(VS.85).aspx. But
RegLocator can only look up single key values, and cannot look up the
sub-keys under a key (which is what we need to get the Python versions).

* We could hard code all the possible versions, and stick all the
corresponding SOFTWARE\...\%(version)s\InstallPath keys into RegLocator.
Then these can be read into properties using the AppSearch table
(http://msdn.microsoft.com/en-us/library/aa371559(VS.85).aspx), and we
could then fill in the ListView table with the install paths. But
AFAICT, there is no way to keep from putting one row into the ListView
table for each version of Python we statically define. Which means a
bunch of inappropriate rows at runtime (e.g. there'd be a row for Python
2.3 even if there was no Python 2.3 on your system).

Basically, the problem is that we'd like to determine what goes into the
ListView table at runtime, but I can only figure out how to put things
into it at the time at which the .msi is built.

I'm going to continue to look into this, and I'd welcome suggestions
anyone has.

The last resort would be to create a CustomAction using a DLL or
VBScript, but I'm really trying to avoid that, both because maintaining
and debugging such code is painful, and because Michael Foord suggested
that some virus checkers will complain about .msi files with embedded
VBScript (probably forcing me to maintain a DLL - ugh!).