Hi there, It has long been a known problem that ITERATE, as a code-walking macro, might confuse CL implementation's source tracking facility, preventing the debugger from locating the accurate form for runtime error (e.g. it often jumps to the top level iterate form, which is often not helpful). My recent patch https://gitlab.common-lisp.net/iterate/iterate/-/merge_requests/24 partially addresses this, but it's only guaranteed to work for simple function calls. Recently I have discovered an IMO much better way: in fact, on my local branch I can get *perfect* debugger source tracking on SBCL and Clozure CL for virtually any forms inside ITER, relying on just a single implementation-dependent interface: (note-source-transformation ORIGINAL-FORM NEW-FORM) Indicate that ORIGINAL-FORM is transformed to NEW-FORM. This implementation dependent interface is really needed, because in standard CL there's no way to express such information. The interface already exists in Clozure CL, and I have a working polyfill for SBCL. Believe me, the source tracking it brings is so good that you, as a ITERATE user, will want it! The question is given that currently ITERATE is purely ANSI CL with no ASDF dependency, how should we go about adding this? I see two options: 1. Include the implementation-dependent note-source-transformation code in ITERATE itself. We can split non-portable code into a different file from iterate.lisp. The advantage is the ITERATE system stays free from ASDF dependency. 2. I can publish a separate NOTE-SOURCE-TRANSFORMATION system, and update ITERATE to use it. The advantage is non-portable code is factored into another system (quite common practice nowadays given the proliferation of TRIVIAL-* systems), and the interface can be used by other code-walking macros. What do people think? Best, @kchanqvq