:Attila old ASDF was a piece of software that wasn't designed for the tasks it is used for today (as in its API, let alone its implementation), and that was causing a lot of headache to "the users" you seem to be defending above.
Indeed, there has been a lot of mission creep in ASDF from ASDF 1 to ASDF 3.3, some of it is explained in my 2013 article http://fare.tunes.org/files/asdf3/asdf3-2014.html (search "Mission Creep" in the article; obviously not covering improvements since, but 3.1 stabilized many ASDF3 APIs and introduced package-inferred-system, while 3.2 had significant internal cleanups and enhancements including for bundles plus major documentation update, and 3.3 introduces proper support for staged builds).
i don't have a strong opinion about this specific warning. to be honest, if i was the ASDF maintainer, it would be fine for me if the warning was off by default, and i would only turn it on in my own CI to send out the PR's and/or warnings to the relevant maintainers, and then let old and/or conservative libs continue to misbehave as they did with the old ASDF.
Actually, I believe the warning is here for a good reason and should be there *by default*—to warn developers about their using a misfeature that was never officially supported nor documented, caused a lot of grief in the past, and has been deprecated for a long time with a better, simpler replacement (typically, replace a dash by a slash) that just works. I am glad that Robert agrees.
I also wouldn't be against introducing multiple levels of verbosity to ASDF (though I'm not willing to do the job for free anymore). Ideally, there would even be a way to get different verbosity levels for systems depending on whether they are mere dependencies (where you'd like to be able to disable all warnings after you pass QA) or software you're developing. But doing this kind of things right would introduce yet another backward-incompatible feature with an "interesting" migration path, which would open its own can of worms and a lot of time to be sunk in engineering, with no reward whatsoever to be expected from the community.
I've done my share of sending patches to unresponsive or ungrateful maintainers, warning people years ahead of an incompatible breakage, etc. I've also done my share of breaking things, even when I did run all the software through cl-test-grid. Mea culpa. [And, sure, we don't have automated enough cross-platform CI. That would be a great feature to add for a new maintainer.]
Anyway, I too am reminded why I chose to spend less time in the CL "community". The Racket, Gerbil Scheme, OCaml and Nix communities are far from perfect, but they are overall less dysfunctional, with less counterproductive passive aggression— oriented towards building new cool things that never existed before, rather than religiously preserving as is the perfect code of our ancestors (that never actually worked far beyond their obsolete use cases). At this point my opinions on ASDF are for historical value only, supposing a future maintainer wonders why the code is what it is rather than worships it as perfect godly gift never to be changed.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I'm not a procrastinator, I'm temporally challenged"