Why? I don't think of SBCL's problems as being particularly related to the language it's implemented in, but a lot more related to the complexity of making an optimizing non-JIT compiler for a language as complex as CL.
the codebase is old and in c. a rust version gives new rust devs a chance to cut their teeth on building a lisp and learning about lisp as well. plus we could get a interop with crates. imagine if cl code could call rust crates for instance.
The codebase is old and almost entirely in Lisp; parts of the runtime are in C, but they're also not the parts that are getting worked on, because they're not where the bugs are (because so much of it is in Lisp).
Unless Rust has gotten runtime reflection without me hearing about it, I don't think writing the compiler in Rust gives you any special powers in interfacing with Rust. You'd get a lot more of a win from parsing the DWARF of a library when you dlopen() it, and using the type information that exposes to be able to use the full Rust ABI rather than the C ABI.
EDIT: Actually, no, even with runtime reflection, that would only help an interpreter, not a compiler.
That still wouldn't give you the ability to perform template instantiations at runtime though -- for that, you'd need to ship the Rust compiler with your Lisp _applications_, since you might be able to invoke a Rust template with arguments at runtime that hadn't been seen before.
If you're looking at work on building a more modern Lisp compiler, check out SICL or Clasp, though as far as I'm aware, those are both early-ish projects.
CLASP may be newer, but it is hardly more 'modern'. There is only limited adoption of CLASP in the Lisp community, because its advantage (excellent integration into C++) is only interesting for a small group of users. At the same time its disadvantages (complex implementation, much slower than SBCL in both development and application, less compiler sophistication for the Lisp user, ...) limit its adoption. CLASP is a special purpose CL with the aim to easily interface to large libraries of C++ code. It maybe be newer and also a great piece of engineering, but it is no competitor to faster implementations. SBCL can compile itself in roughly a minute on a current machine - something like CLASP takes a lot longer. With SBCL we'll have already the much faster and more responsive implementation.
