Dear Robert & asdf-develers,
I was discussing max version constraints and the havoc they wroke on Haskell land, yet the legitimate use they have in toplevel projects integrating many libraries, and figured that maybe the solution could be a difference in treatment between max version constraints found in a toplevel asd file (the one you directly call operate on) vs ones found in subsequently loaded .asd files: a broken constraint at the toplevel would cause an error, whereas a constraint broken outside the toplevel would only issue a warning—a warning that would suggest either removing the constraint (because its value outside the toplevel is dubious or advisory only) or updating it (since the toplevel works without it), or adding it to the toplevel too (because the toplevel doesn't actually work without it). The warning can be hushed the usual way if desired, and both the warning and error would inherit from a common condition.
Technically, to implement this, the main methods of load-asd and operate would bind a special variable to the path of the .asd file (or its truename* ?) if the binding is currently NIL, and the constraint checker would behave differently depending on whether the component-path of the current system matches it or not. (This is a rough idea that has not been tested.)
Would this solution work for you? It seems to me that it should make everyone happy.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org “All problems in computer science can be solved by another level of indirection.” — David Wheeler