> Scala eventually gave up C# precisely because CLR reification proved a huge challenge with Scala semantics.

In other words, Scala was designed on a hack involving JVM's type erasure, then authors found out the hack can't be ported to CLR. That's another way to view it. Type erasure is a half-baked mess in original Java, it was causing headaches right with the first version of generics...

Type erasure is not a hack. It's the most common technique in typed languages. It causes what is, at worst, a minor inconvenience in the Java language in exchange for making the Java platform a very attractive and very convenient target for languages. Reification -- and I believe .NET is the only platform with variance that does it -- makes a very inconvenient compilation target for any language not designed around it.

That sounds as ex post facto justification. IIRC the designers hit the issue once they started implementing generics and the gravity of the situation became apparent just at that time. Then another set of hackers figured out a way to utilize it for language interoperability. I am not saying CLR's final implementation is great either, but it addresses some points JVM missed as they had time to learn from SUN's mistakes, while making their own errors in the process as well. Language/platform design is notoriously difficult and unpredictable.

> That sounds as ex post facto justification.

The initial reason was indeed backwards compatibility. As it turns out, compatibility with Java 1 unintentionally yielded compatibility with future languages too.

Because of this flexibility (ex post facto notwithstanding), the JVM became the most popular VM target ever.

Note that GraalVM -- which from day 1 intended to be a multilingual VM -- also uses type erasure.

---

Know that there is more than conceptualization of a type system, and in particular a parameterized type system. C vs C++ vs Java vs Haskell. The more of this is baked into the runtime, the more reflection can be done at runtime, but the less interop can be done with other type systems.

(There is a reason why C not C++ is the de facto FFI standard and its not just age.)

The original issue was compatibility and interop between two languages with different variance strategies. It's just that those two languages were two versions of the Java language. Calling it a "justification" is also misplaced: baking a variance strategy into the runtime makes the runtime very over-fitted to a particular language; AFAIK this is only done by .NET. So if it's a "justification" it is a very reasonable one. I don't think either of the approaches is a black-and-white mistake, but I personally very much prefer Java's. The loss is a very minor inconvenience (mostly the inability to overload methods with different generic arguments, e.g. foo(List<String> x) and foo(List<Integer> x)), and the gain is that the Java platform is a great compilation target for many different languages. Whether or not those who made this decision had other languages in mind is irrelevant; it's a very good decision, even though some would prefer the opposite one. It's certainly not a mistake and not a hack. It's not a hack because it is a well-known, well-understood, common compilation technique; it's not a mistake because there is no alternative that's clearly better, and many (myself included) think it's significantly better than the alternative chosen by .NET.