Erased generics will surely stay and are a good thing. If they were removed, Scala would be in trouble (or rather, scalac would have to perform erasure itself, which in turn would mean that interop from Java wouldn't be good anymore).
What's broken in the JVM isn't erased generics but instead runtime reflection that is a lie due to erasure. Type erasure though is definitely an example of Java getting something very right for the wrong reasons.
Are you attempting to separate the concepts of specialization vs reified generics? Java does neither right now, and both effects are due to type erasure -- the runtime simply doesn't have the necessary information. I'm not quite sure where you're trying to draw the line.
Furthermore, runtime specialization (as opposed to compile-time) would seem to require reified types. So that further confuses things. But you can definitely have reified types without specialization, which I think is the point that you are trying to convey.
It permits languages on the platform with substantially-richer compile-time type systems than the primary language on the platform with good interior stories (this was, IIRC, a substantial problem with Scala.NET.)
Is it, though? The most basic implementation, where things are still erased at runtime by the JIT, should be fairly simple, although it will not give the expected perf gains, of course.
Either way, CLR and C# did it a long time ago, and in the same time period when Java acquired its type-erased generics.
What's broken in the JVM isn't erased generics but instead runtime reflection that is a lie due to erasure. Type erasure though is definitely an example of Java getting something very right for the wrong reasons.