Right now slime.el is 6250 lines, which makes it one of the larger programming modes line-count-wise. Besides making byte-compilation frustratingly slow, this size hides useful sub-components that (IMHO) could be made into their own, separate modules and used outside of Slime. For example, once the Slime-specific evaluation code has been factored out, there's a nice generic Elisp REPL hiding in there. With a bit of work today, I was able to turn it into a serviceable 500-line tool for interactive Perl development. While I did away with the asynchronous I/O features for simplicity's sake, I imagine these could be kept with a bit more work. The Xref browser (which I've never seen in action, not having CMUCL at hand) could be a similarly useful component.
The long-term upside of this is that many of the Slime interfaces, which are quite nice, could be used as a common face for other languages that support interactive development and introspection, like Perl, Python, and Ruby. The downside, of course, is that this would constrain Slime's development. However, since Slime is stable enough to have a manual now, this may not be such a problem.
Opinions?
/s