I think you are falling into the mistake of associating what you call design with features. How features are implemented and how consistent they are with some pure notion of their role is secondary to how they serve the high-level design
goals. Once you understand Kotlin's design
goals you see that the features and their implementation make a lot of sense. If you think the features aim to serve another goal, then the features might seem inconsistent. Outside of academic languages, language features exist to serve particular purpose, and so their "academic" form may be compromised to serve that purpose better. There is no point in isolating features from their purpose and then arguing over them without first understanding their goal
in that particular language, as the same feature can serve different (or subtly different) purposes in different languages, or a feature must be twisted in order to allow the goal to be better achieved. There is no way to say whether a feature is good or "broken" without first analyzing the language's goals, and a feature that may be bad in one language may be great in another.
As Scala (or Ceylon) has such radically different goals from Kotlin, it doesn't make much sense to discuss which features were imported and how without first understanding the why. Kotlin's designers didn't say, "I like this Scala feature but not that one"; they said, "we have this goal and this Scala feature serves it but that one doesn't". A language is not measured by what features it has, but by how those features serve its goals, and whether those goals are appropriate to begin with (i.e. provide a good cost/benefit ratio).