Inability to reasonably operate an API that has that StringTemplate type somewhere in a method signature would be a dramatic change of direction for kotlin. I'd

Inability to reasonably operate an API that has that StringTemplate type somewhere in a method signature would be a dramatic change of direction for kotlin. I'd be surprised if they didn't already have something in the pipeline to support \{it} strings on the syntax level, it's not like they pretend java-side progress didn't exist. The existing ${it} syntax is tied to string on the output, so it can't be repurposed. The java approach on the other hand keeps the output generic, so that it would also keep the door open for similar not-string compatibilities in off-JVM kotlin implementations. Whereas the ${it} the syntax kotlin already has couldn't do that. An approach like changing its semantics to define something that isn't a string when it exists at a StringTemplate.Processor call site would be terrible I think, php-grade terrible. At least as long as they don't also introduce that formatter-dot-template syntax which I'd consider a pointless redundancy with what kotlin already has: formatter{template} is already possible, expect for a way to write a template literal that resolves to something other than string. What I certainly wouldn't expect is anything reminiscent of "automatically imported into every Java source file".