There are various situations you get into in Clojure where the easy way out is "just restart the REPL." This is unfortunate, because

startup time is slow

often REPLs have a ton of useful context built up

I believe these problems could be entirely solved in a contrib library of helper functions for REPL development. This a significantly better than making changes to Clojure, which must pass a high bar and be carefully assessed for possible affects on exiting code. It is also consistent with Rich's desire to more clearly delineate development vs. production functionality.

Having defprotocol check to see if any signatures have changed before generating a new Interface would possibly relieve some of the pain around recompiling namespaces that define protocols (assuming they are often recompiled for reasons other than a protocol change).

The only disadvantage to pomegranate is that it pulls in aether, and other transitive dependencies. I now have this working in ritz, which uses pomegranate to resolve dependencies, but uses classlojure to manage the classloaders, since there is more than one. It takes some care to create a new clojure runtime if any existing dependency has been removed or replaced, but otherwise creates a child classloader of the current classloader. The nrepl-project sub-project in ritz contains the start of a general project management middleware for nrepl.

Ritz has it a little easier, since pomegranate can run in the debugger jvm instance, and doesn't have to go into the user's jvm. With a single jvm, you would probably want to run pomegranate in a separate classloader to avoid dependency conflicts, etc.