Lately I've been focusing on running things through some very generalized code paths to cut down on variant behaviors--and ensure systemic correctness in handling things, like "dual state" object fields that come from calling an accessor function vs. being a literal value. The indirections caused by this generalization have slowed things down a lot, and so I'm being tempted into doing some optimizations.
But before going after optimization, I need to heed my own advice, and make sure all the important features are working first... and DEBUGGING is a very big feature that needs to work.
Being able to go through code step-by-step is important for people writing sophisticated things, but even more important for beginners to get their bearings.
Ren-C's Design Has Considerations For Debugging
While you wouldn't know it from the lack of debugging features, I've actually been weighing the needs of a source-level debugger while putting things together.
The best sign that you can see that I have been considering it, would be the Parse Debugging Demo:
Mechanically, what I have in mind for debugging as a whole has a some things in common with what you see there.
(I had a longer post in mind--but today I'm trying to flush out all the drafts in Discourse--and this as far as I got...which is to say: RESIST THE TEMPTATION TO OPTIMIZE DUAL STATES BEFORE DOING AT LEAST SOME BASIC DEBUG/TRACE DEMOS!)