Having incompatible String implementation would have too much drawbacks compared to possible advantages. Built-in Strings receive special JVM optimizations and are used everywhere. Incompatible Strings would need to be converted back and forth when interfacing with Java code - and you can’t use wrapper classes as String class is final so can’t be extended. Additionally, Java’s Strings are already immutable so they don’t make functional programming harder (in contrast to standard Java collections which aren’t a good choice for functional programming).

Correct. By and large, Scala uses the underlying “Java” types (really, JVM-standard types) where appropriate, so that we can interoperate with other JVM languages more easily. It then often makes more methods available for those types by using typeclasses and implicits…

Worth saying that it would actually be nicer if Scala had a distinct type.

Crummy API like "".split could be avoided. The implementation of scala.String as a string of the underlying platform should be a backend concern.

Really tired of hearing questions about confusing String#split, obviously. And it’s not a newbie issue. It is a terrible productivity drag on every user of the language. So highly paid Scala programmers also waste billable hours looking up the Java API b/c it’s terrible.