SBCL and Slime do strange things when I try to use Serapeum

Question

I'm getting very strange behaviour when I try to C-c C-k the following code into the SLIME REPL running SBCL:

(eval-when (:compile-toplevel :load-toplevel :execute)
  (ql:quickload "serapeum"))

(defpackage #:foo
  (:use #:cl #:serapeum)) ;no symbols to export currently

(in-package #:foo)

The operation fails, and SLIME spews the following into my face:

    failed AVER: (NULL CURRENT)
This is probably a bug in SBCL itself. (Alternatively, SBCL
might have been corrupted by bad user code, e.g. by an undefined
Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers
from alien code or from unsafe Lisp code; or there might be a
bug in the OS or hardware that SBCL is running on.) If it seems
to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists,
which you can find at <http://sbcl.sourceforge.net/>.
    [Condition of type SB-INT:BUG]

Backtrace:
  0: (SB-C:COMPILER-ERROR SB-C::INPUT-ERROR-IN-LOAD :CONDITION #<SB-INT:SIMPLE-FILE-ERROR "~@<~?: ~2I~_~A~:>" {1004F4CAD3}> :POSITION 0 :STREAM #<SB-SYS:FD-STREAM for "file /home/koz/quicklisp/dists/quickl..
  1: (SB-C::READ-FOR-COMPILE-FILE #<SB-SYS:FD-STREAM for "file /home/koz/quicklisp/dists/quicklisp/software/split-sequence-1.1/split-sequence.asd" {1004EEABD3}> 0 SB-C::INPUT-ERROR-IN-LOAD)
  2: (SB-INT:LOAD-AS-SOURCE #<SB-SYS:FD-STREAM for "file /home/koz/quicklisp/dists/quicklisp/software/split-sequence-1.1/split-sequence.asd" {1004EEABD3}> :VERBOSE NIL :PRINT NIL :CONTEXT "loading")
  3: ((FLET SB-FASL::LOAD-STREAM :IN LOAD) #<SB-SYS:FD-STREAM for "file /home/koz/quicklisp/dists/quicklisp/software/split-sequence-1.1/split-sequence.asd" {1004EEABD3}> NIL)
  4: (LOAD #P"/home/koz/quicklisp/dists/quicklisp/software/split-sequence-1.1/split-sequence.asd" :VERBOSE NIL :PRINT NIL :IF-DOES-NOT-EXIST T :EXTERNAL-FORMAT :UTF-8)
  5: (UIOP/UTILITY:CALL-WITH-MUFFLED-CONDITIONS #<CLOSURE (LAMBDA NIL :IN UIOP/LISP-BUILD:LOAD*) {1004EE584B}> ("Overwriting already existing readtable ~S." #(#:FINALIZERS-OFF-WARNING :ASDF-FINALIZERS)))

...and so on for ages and ages. I've checked and this does not happen if I just load it into SBCL using sbcl --load on the file that contains this code. Basically, what the actual hell is going on, and how can I make it not do that?