(I’m a bit late to this discussion, but the other discussion on almost the same topic is still active, and my comment fits better in this thread)
An important use case for a type class / extension type-like feature would be passing an object of a type, e.g. String, to a method that expects an interface type that String does not implement, e.g. Addable. I think it would be quite useless to require the interface to know about some Kotlin magic such as an extra hidden self parameter, since that would break Java interop. Then this feature would not help at all if the expected interface was a pre-existing plain old Java interface used in a Java library. While I would like to have some nice syntax in Kotlin to use type classes, I don’t think there is a way around having an implementation based on wrappers. AFAIK wrapping the String in a wrapper that implements Addable is the only Java-compatible way to implement this. And if wrappers are used for interop with Java it is probably best to use the same implementation in pure Kotlin code as well.
Regarding the problems with wrapping and equality, such a wrapper would only be passed to code that expects an Addable (in this example). If that code is written in Java it would be unlikely to try to compare the wrapper to a string and expect both objects to test equal because as far as this code knows String does not implement Addable. If the code is Kotlin the compiler could insert some extra magic to remove the wrapper. And besides, using wrappers is also the usual Java way to pass an object Foo to a method that expects a Bar. While it isn’t a leak-proof abstraction it often works well enough.