As a person who continues to code and enjoys
doing it in Python, I think you touch on a number of great points, but a DNS-style lookup of packages is not a significant advancement to me except in the case of small embedded devices, which I no longer work upon.
Currently, I generally (not always, but generally) have to follow this design cycle to integrate python packages, even standard ones:
1. Find a package that meets my requirements and possibly download it
2. Understand the API
3. Extend the API via wrappers, subclassing or decorators for my application
4. Use the custom API in my appl
5. Package everything into a single distribution
Steps #2, #3 and #4 are the big ones. In comparison steps #1 and #5 are relatively trivial.
The major work is BECAUSE everyone has a different interpretation of a "good" API. You mention your frustration with database packages. Taking extremes, the pysqlite, RSDP (from your 2005 article) and ZODB APIs are pretty nice once you learn them but they are radically different.
You seem to have choosen SQL via XML-RPC as the DBMS API of choice and, based upon that, you suggest a python standard library. However, it excludes everything non-XML and non-SQLish. Thus I see another set of "standard" libraries OR just have everyone say "There's only one way to do this", bite the bullet and use your API. Another common API problem is logging - everyone has a different logging interface.
And I didn't even talk about maintaining a logical migration path for "standard package" versions. Just look at the migration of sqlite, pysqlite2 and sqlite3 for an example.