No. Having a byte-code interpreter which is essentially an assembly language allows you to create any type system you want. It is wwhen you require interop with an existing type system that you are constrained.

>Otherwise it would be absolutely forced to essentially conform exactly to Java's type system since the targeted bytecode would require all sorts of type annotations which would have to be correct-according-to-java.

One could argue that it would be prudent to base your type system on the type system of the platform you choose. Essentially what Scala chose the route of not integrating deeply with the platform type system. That choice could have been made regardless of how advanced the type system of the platform was.

So if the platform had offered reified generics, Scala could still had chosen to ignore those and gone with type erasure. But they could also have chosen to support reified generics. I'm interested in what concrete constraints that would have imposed on Scalas type system, except for interop with Java.

Ironically, the chosen design has forced Scala into adorning with all sorts of type annotations to ease interop with Java: It has to lie about the generic type argument the same way Java does in the type metadata, i.e. "consider is a collection of Shapes. Note: it may be other object types so you must perform downcasts yourself*".

Not with anywhere near decent performance.