Mmmh... if we push and pop stack frame indications, isn't it enough to build a debugger?
The runtime part of the debugger can be a optional listener in add/popStackFrame which suspends the execution when a breakpoint is encountered (detected using the stack element's location).
And we can also associate an additional object to a StackTraceElement that will give access to the variables in the element's scope. This will be e.g. an InvokeContext for the TreeProcessor or a [JXPath|Jexl]Context for JXTemplate. This allows the debugger do display and even modify the variables that drive the current request's execution.
Without getting into all the details, I think a proper API for a global debugger would require quite a bit more infrastructure than what you're suggesting. Also with the fast edit - reload - test cycle provided by Cocoon, "println()" style debugging seems to work quite well. A source-level debugger is mainly required when the development turnaround cycle is long (e.g. J2EE apps). For example, although Rhino has a JavaScript debugger, I rarely use it because println() debugging is usually more efficient.
Regards,
Chris
