Here is a patch (with respect to d20ea551c018c46439874f6911e4522289c1196a which you just pushed) which should take care of the test-encodings.script failures. The issue in my case was that I was running tests for alisp followed by alisp8. The asdf/build/fasls/alisp/asdf.fasl  was being created originally by alisp, then loaded unmodified by alisp8. Because the pushnew of the :asdf-unicode onto *features* was being hard-coded into that fasl by alisp at compile time, this feature was coming into the system when asdf.fasl was being loaded into alisp8. So alisp8 ended up incorrectly thinking that it had :asdf-unicode, which caused test-encodings.script to become confused. 

Same deal with mlisp/mlisp8.

Of course when I ran a fresh test only with alisp8, this problem was not presenting.

One might argue that the fasls for alisp and alisp8 (similarly mlisp and mlisp8) should be separated. And in full ASDF of course this is done already with the implementation-identifier --- so one would never have noticed the issue in day-to-day operational use of ASDF. 

But separating the fasls between mlisp/mlisp8 and alisp/alisp8 should not be necessary; in Allegro you are supposed to be able to compile a fasl with alisp (mlisp) and load it with alisp8 (mlisp8), and vice-versa. It's specifically designed to be able to do this. So even though ASDF normally separates its fasls in production use, I still think code should be written so as not to violate the expected ability to compile interchangeably like this (note that it's also supported to compile a fasl with mlisp and load it with alisp (but not the other way around) --- but that's a different issue entirely). 

This has not popped up again.  All 15 tests in the attached "run" script now run to completion with no failures. So I'm going to leave it be for right now...