I've just committed my version of Tobias' idea about including Java stack information in stack traces when relevant to the trunk. The associated work for SLIME has been committed to SLIME HEAD.
From the commit message of [svn 12105][1]:
Split StackFrame abstraction into Java and Lisp stack frames.
From the original patch/idea from Tobias Rittweiler this introduces more information of primary interest to ABCL implementers such as when a form like (make-thread #'(lambda ())) is evaluated
All users of EXT:BACKTRACE-AS-LIST should now use SYS:BACKTRACE, the results of which is a list of the new builtin classes JAVA_STACK_FRAME or LISP_STACK_FRAME. The methods SYS:FRAME-TO-STRING and SYS:FRAME-TO-LIST are defined to break these new objects into inspectable parts. As a convenience, there is a SYS:BACKTRACE-AS-LIST which calls SYS:FRAME-TO-LIST on each element of the computed backtrace.
Refactorings have also occurred on the Java side: the misnamed LispThread.backtrace() is now LispThread.printBacktrace(). LispThread.backtraceAsList() is now LispThread.backtrace() as it is a shorter name, and more to the point.
Java stack frames only appear after a call through Lisp.error(), which has only the top level as a restart as an option, so concerns about trashing the stack are not really relevant (an early concern of mine).
[1]: http://trac.common-lisp.net/armedbear/changeset/12105