I think you are describing a source to source translator, and an awfully fancy one at that. A translator generally would be trying to map or maintain the struct

I think you are describing a source to source translator, and an awfully fancy one at that. A translator generally would be trying to map or maintain the structural idioms in the source code, allowing for human understanding or maintenance of the translated code. But to improve the coding style by detecting latent idioms seems a bit much even for most translators. I always considered a transpiler to be closer to a translator than to a compiler, but without the translator's concern for maintaining human-readable code. For me, the boundary between transpiler and compiler is in the runtimes. A transpiler would be targeting the whole runtime of a target language, i.e. one with non-trivial type systems, flow control/exception handling, and memory management/GC. The transpiler maps source language runtime concepts to target language runtime concepts in a relatively straightforward fashion. A compiler targets some lower-level abstract machine language and provides its own distinct runtime system as well. A similar boundary exists for interpreters, where a meta-interpreter does relatively high-level source-to-source conversion before delegating to a target language interpreter and its runtime. These meta-interpreters are akin to transpilers, while full blown interpreters are akin to compilers, targeting a lower level abstract machine and providing their own runtime systems.