I'll look at this in more detail, but I can at least answer one question right now:

"The bona-fide known bug: the Debian package mantainer for Python decided to change "site-packages" to "dist-packages" in 2.6, for reasons I still don't quite understand."

This was done as an accommodation to upstream Python developers.  A from-source build of Python installs into /usr/local by default, with a site-packages situated there.  But the Debian interpretation of the FHS states that site-installed (i.e. not through the package manager) add-ons to Python should also live in /usr/local, and /usr/local/lib/pythonX.Y/site-packages was chosen as the most obvious place for that.

Unfortunately, this meant that if you installed Python from source using the defaults, it was possible to clobber either your system Python or your from-source installed Python by installing third party packages to an unintentionally shared directory.  This was a real problem.

Now, the Debian answer (probably rightly so) was that Python's from-source defaults should install into /opt not /usr/local, but this broke a decade's (at least) convention from upstream.  The compromise was to keep Debian's /usr/local interpretation of the FHS, but to choose a directory that would not conflict with a from-source installation of Python.  Thus dist-packages was chosen.  To keep the system Python consistent, Python packages installed via apt are installed to /usr/lib/pythonX.Y/dist-packages too.

I've had discussions with developers on both sides.  It's not an ideal solution to anyone, but I thought it was the best compromise available at that time, and still do.