What do you mean by "JVM-aligned" and how is Kotlin more JVM-aligned than Scala? Speaking as someone who uses Scala on a daily basis and never touched Kotlin.
Kotlin types and Java types are much more compatible than Scala types. No need to use converters. Also, Scala leans very FP, while Kotlin and Java don't, so they are also more similar in that regard, though I don't know if that's what "JVM-aligned" means here. Overall, Kotlin and Java just have better interoperability than Scala and Java
Kotlin sold its soul to Mountain View overloards, while JetBrains it trying to create a Kotlin platform of its own.
Now it is full of @JvmSomething annotations and one needs to rely on KMM for writing portable code across JVM and ART.
Thanks to #KotlinFirst and Google's relutance to improve Android Java, Kotlin will have to choose which eco-system they want to provide a platform first developer experience without forcing devs to write FFI annotations and wrapper libraries.
The JVM is designed to execute the constructs of the Java language. Scala compiles to JVM bytecodes, but it does a lot of (very cool!) things that are not natively supported by the JVM, and thus tend to be pretty expensive. Scala's pattern matching, for example, goes beyond what can be efficiently expressed in the JVM.
As a rule, Kotlin does not take this approach. Instead, almost all the constructs in Kotlin can be cleanly expressed in JVM bytecodes.
Reified generics is a good example. Kotlin only allows them when a function can be inlined, since in those situations, you don't actually need generic arguments, since the code in the inlinable function can be dropped in place. This allows for the convenience of reified generics -- but only if you're willing to live within the limitations of the inline restriction. (And it's also elegant, since it'll be easy to relax the constraint once the JVM adds the needed support.)
I've run across one or two things in Kotlin that don't translate to JVM bytecode elegantly, although I'm struggling to find a good example off the cuff. They're definitely the exception, though, whereas the Scala team took a more radical approach.
It's not clear that bytecode changes are needed for efficient pattern matching support.
Java is getting pattern matching support. The related JEPs mention that:
The implementation will likely make use of dynamic constants
https://openjdk.java.net/jeps/309
I strongly suspect that Scala could be more efficient if it used it too. However I have no idea if this could improve compile time. (kotlin has until now procrastinated implementing pattern matching support because they say it increase compile time, but maybe that doesn't hold with constant dynamics)
