For some reason the Kotlin blog tends to eat my comments (maybe some spam filter) so I'm posting them here instead.
Re: infix functions. I appreciate and agree with the general direction. However the current behaviour is convenient for Java classes that have been deliberately augmented to support Kotlin operator overloading. I maintain a library (bitcoinj) which just did this: the Coin value class is a bit like a BigInteger, and now has methods to let Kotlin users write natural looking code. It’s a lot of additional overhead and annoyance to create a separate Kotlin library just to contain a handful of extension functions that do nothing beyond adding the “infix” modifier. Perhaps the requirement for this modifier could be relaxed for Java classes, or an annotation that can be applied in Java made available.
Re: backing fields. The rationale here does not seem very strong to me. Yes, it may be a little unintuitive how to include the backing field in a string template, but simply using concatenation can fix that, or switching to e.g. %field instead of $field. Making an identifier change its meaning inside its own definition has the potential to be confusing (it looks like it should trigger a stack overflow), and requiring a separate bit of boilerplate for the case where a class wishes to bypass the getter/setter code for its own use is ugly/verbose.