You have provided some defining properties that might allow for distinction, but you have not given any reasons for why people make a distinction.
But perhaps we can suss it out. Given the statement "Borgo compiles to Go", what important information is lost that would be saved if "Borgo transpiles to Go" was used instead?
In the statement "XYZ is a compiler/transpiler", it does. It doesn't hurt to have a word that is more specific than others. Otherwise we should just refer to compilers as an "app" :)
It reminds me of how my 5-year-old son always corrects me when I tell him to get in the car—"you mean the van!". I have tried to explain to him that a minivan is a kind of car, and he's just about getting it, but it's been a challenge for him to grasp.
This thread chain is in response to jerf's comment "transpiler shouldn't be a word" (simplifying his comment for brevity's sake)
> The word "transpiler" propagates the misunderstanding that there is something special about a compiler that emits machine code, that requires some special "compiler" techniques for special "compiler" purposes that are not necessary for "transpiler" purposes because "transpiling" requires a completely different set of techniques.
In context of the parent comment I read this to be a reaction to someone insisting that we use "transpiler" instead of "compiler"—more an observation of what is happening here than a call to stop using the word altogether.
> Ultimately, "compiler" isn't a bright shining line either... I can take anything and shade it down to the point where you might not be sure ("is that a 'compiler' or an 'interpreter'?"), but the "transpiler" term is trying to draw a line where there isn't even a seam in the landscape.
Okay. What important information is lost in "XYZ is a compiler" that would be gained in "XYZ is a transpiler"?
> It doesn't hurt to have a word that is more specific than others.
It can if the intent is not properly understood. And so far I'm not sure we do have that understanding.