> They are very difficult to debug because they're processed too early.  

.pth's are processed by site.py, so no more difficult than site/sitecustomize.
You can e.g. run `site.addpackage(<dir>,<file>,None)' to debug the logic.

> They usually contain globs of inscrutable code.

An ability to contain code is there for a reason: to allow a module do something more intelligent than adding hardcoded paths if needed (e.g. pywin32 adds a subdir with .dll dependencies to PATH).

A chunk of code is limited to a single line -- a conscious limitation to deter misuse 'cuz search path setup code is presumed to be small.

If someone needs something other than path setup, they should do it upon the module's import instead.
If they insist on misusing the feature, Python's design does what it's supposed to do in such cases: "make right things easy, make wrong things hard".

If there's a valid reason to allow larger code chunks, we can introduce a different syntax -- e.g. something like bash here-documents.

> Exceptions in pth files can get swallowed in some cases.

If this happens, it's a bug. A line from .pth is executed with "exec line", any exceptions should propagate up the stack as usual.

> They are loaded in indeterminate order.

Present a use case justifying a specific order.
I can see a probable use case: a package needs to do something using its dependencies, so any .pth for the dependencies should run before the one for the package.
But I can't see why that package can't do this upon its import instead (saves unnecessary work if the user won't be using that package in that session, too).
The only valid case I can see is if the package is using some 3rd-party import system (e.g. a .7z archive or some module repository) that needs to be loaded first for its search path to make sense.