Sorry, "debug the output" was a really confusing way to say what I meant. What I meant was users will want to debug their code, and the way they do that is often affected by what their code is compiled to.

With a transpiler, it's fairly common to actually debug using the generated output. That pushes many transpilers to place a premium on readable output that structurally resembles the original source code, sometimes at the expense of performance or code size.

Other times, users will rely on things like source maps in browsers. That gives more flexibility to the transpiler author but can make user's debugging experience weirder because things like single-stepping can get fuzzy when a "step" in their source program may correspond to something very different in the transpiled output.

In compilers to lower-level languages (machine code, bytecode, etc.) there is a strong implication that most users can't debug the output, so the compilation pipeline and tools are obligated to have pretty sophisticated debugging support.

In other words, different tools, priorities, constraints, etc. Having a separate word to help tease these apart seems useful to me.

All of that I view more as examples of how immature the tooling is on the frontend, rather than an inherent distinction between source->source and source->machine compilation.

I remember crappy C toolchains that only gave you a .map file for debugging. It was just table of where the linker put the symbols from the intermediate objects. Hell, there were a lot of really crappy C compilers then that looked way more like babel than gcc. They basically just parsed into an AST and walked it to spit out asm, hardly doing any optimizations.