I would like to forestall facile answers to the above claim, too. I don't just mean "SLIME would have to handle IN-READTABLE." SLIME would have to be fixed, yes, but also ELI, Allegro Composer, Hemlock (or whatever the CCL IDE is), LispWorks whatchamacallit, etc., etc.
True. However, lack of support there is not a regression. Things that used to work still will work. New things that may work will require additional support, but we can leave that up to those who will use those things. I suspect Attila and the dwim.hu guys have extensions like that already.
it's a simple thing that can easily be adapted to named-readtables, and i'm willing to help doing that if things get moving on this front:
http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.def;a=headblob;f=/inte...
it's loaded with hu.dwim.def+swank.asd
we have a develop-op in hu.dwim.asdf that at the end looks for all the *+swank systems, and loads them if all of their dependencies are already loaded. (it also does a (declaim (optimize debug)), and various other changes with logging, etc... depending on what system is loaded with develop-op)
ASDF should not demand a programming style that doesn't have full support for in-editor dynamic code writing and maintenance.
ASDF doesn't demand anything; it just enables new extensions by providing hygiene.
this reminds me of the general idea of backwards compatibility: people who want to live without this feature can chose not to upgrade, as always. or if they need the new stuff, then they can just patch asdf locally to disable the enforcement of this. or asdf could even accommodate this with a defsystem property that can opt a system out of this otherwise useful isolation.
*or* this feature may not clearly be an improvement in general, but i'm not convinced about that for now.
These extensions may in turn demand editor support,
either way, if you use reader syntax in CL then you'll be neck deep anyways into duct taping things together, unless an infrastructure is set up that people agree to use.