Description
ASDF 3 supports looking up a system foo/bar/baz in foo.asd, where foo is the primary-system-name of foo/bar/baz. That foo.asd may explicitly define secondary systems with defsystem, and if the primary system is using the new class package-system, this will implicitly define one system per lisp file under that hierarchy.
Quicklisp, if and when it adopts ASDF3, could
A- (simplest solution) use primary-system-name to extract the name of the desired .asd file, and deal only with primary names, and/or
B- (more elaborate, I don't think it's needed) deal specially with generated systems that are not defined in the .asd file itself, by introspecting the (registered-systems) after every load-system, to deduce the minimal toplevel systems that define it, which could generalize the handling of builtin systems (ugh), and/or
C- (overkill) recognize specially asdf/package-system extension, and/or
D- just ignore systems it couldn't track, when listing dependencies of things it did manage to build.
I recommend A only.
Background: ASDF 3.1 now supports the (one file, one package, one system) style of programming in a way compatible with quick-build and similar to faslpath. This is also available as an extension to ASDF 3.0 using asdf-package-system (part of Quicklisp). The only public library using it is lisp-interface-library, though Alastair Bridgewater, Drew Crampsie and I have been using it in private software, too.
While ASDF 2 and earlier don't explicitly support primary-system-name, it accepts systems with secondary names explicitly defined in a foo.asd, and will not associate a portably valid name to a system with secondary name if it hasn't been defined in a previously loaded .asd file — thus the new system is conservative extension. People also used to define a lot of secondary systems that didn't follow this convention, which in the past have led to clashes as well as asdf not being able to find these systems automatically by name. The extension thus serves a needed purpose.