Dear Don,
sorry for a late reply.
The intended way to use ASDF in your case would be to use two or more systems, that may be defined in the same .asd file (using the / syntax to name a secondary system: roan, roan/core, roan/sqlite, etc.) or separate .asd files (using - or . as a separator).
This way, you can unambigously name what is or isn't loaded in a given system in a way that doesn't depend on configuration.
For a system that goes to lengths at doing the right thing with respect to ASDF yet does some automatic configuration detection, try net.didierverna.clon. It has ...clon.core and ...clon.termio systems, and a special ...clone.setup/termio for autodetection.
I recommend strongly against using user-specified *features* to control what does or doesn't go into a system (as opposed to system-provided or system-deduced features).
Also, regarding people using disparate versions of ASDF: if you can always ship with the latest ASDF version and depend on its features. Also, implementations released in the last two years include ASDF 3.1.2 or later (which unhappily doesn't include clisp).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you think health care is expensive now, wait until you see what it costs when it's free. — P.J. O'Rourke