Thank you for the bug report. Unfortunately, this problem isn't easy to fix. The problem is that READ-CHAR and other blocking input functions on the slime-input-stream enter a nested/recursive event processing loop. The loop is terminated on a matching input event but the other events are processed inside READ-CHAR.
This nested event loop is obviously problematic. In this situation it would probably be more appropriate to queue the non-matching events and process them later. OTOH, it feels natural to run the debugger in an nested event loop. It's not so obvious when queueing is appropriate, especially if the same code should be useable with and without threads.
Another problem is that the REPL buffer only switches to "read-mode" if the Lisp side called something like READ-CHAR. Since Emacs can't reliably know whether the Lisp side is still/already inside READ-CHAR[-NO-HANG] it would be better to always send the same events and let the Lisp side make the final decision.
The problem is known but it doesn't seem to occur all that often in day-to-day use. Fixing it requires some redesign and it's not entirely clear how to do this "right".
Helmut.