Per my recent post to launchpad, I don't think dependency updating is the fatal flaw in D-D-O. D-D-O's bad interaction with the package system is worse.
Specifically, D-D-O cannot be used to introduce ASDF extensions unless those ASDF extensions live in the ASDF package. Otherwise, by the time a DEFSYSTEM form is read, the enclosing package's imports are already established. This means that ASDF has no protection against namespace pollution, since extenders are practically forced to add symbols to ASDF.
For example, we have a FIVEAM-ASDF extension that introduces a new defsystem class that has features for using 5AM as an implementation for the TEST-OP. But we cannot put a DEFSYSTEM-DEPENDS-ON for FIVEAM-ASDF in a system and reference FIVEAM-ASDF:FIVEAM-TESTER-SYSTEM as the system class, because the FIVEAM-ASDF package does not (in general) exist when the enclosing DEFSYSTEM is read.
I can think of three ways of handling this:
1. Deprecate and remove D-D-O. This seems undesirable, since D-D-O is commonly used.
2. Replace the use of the lisp reader for processing DEFSYSTEM forms, and introduce some kind of parser. This seems like an enormous amount of work and difficult to get right.
3. In some way extend the keyword-processing features of DEFSYSTEM to allow it to reference symbols that are not only in the current package and ASDF, but also programmer-specified packages. Unfortunately, processing of keyword symbols in DEFSYSTEM is very case-specific -- we know particular locations where there use is permitted, and handle each one specifically. Without a cleaner way to handle this, we are likely to simply be backing ourselves into alternative #2. OTOH, if we *could* do this, it would be a great solution, because it would maintain the maximal amount of backwards-compatibility.
This is the problem I would most like to see solved in ASDF.