For what it's worth, Brian Goetz doesn't see type-erasure as a such a failure and defends the design choice[0].
Erasure is the safest way to implement generics for a long list of reasons. Reification comes with a lot of downsides, which is why most languages that support parametric polymorphism use erasure.
Aside from the video I posted from Brian Goetz most of what I've read is just comments about how much people like reification in C# and how annoying those edge cases in Java are (i.e. stories from practitioners not language designers.)
I'd love to read more.
1. Erasure keeps you honest and prevents you from second guessing the compiler by limiting the introspection you can perform on your code.
2. Reification puts up a very high barrier to interop. Erasure systems are much more welcoming to implementing multiple languages and multiple type systems on top of them. For example, the scala.net project was abandoned because it was impossible to represent Scala's type system on .net's reified platform.
3. Reification imposes overhead because of the multitude of extra runtime checks that need to be performed.
4. Most the benefits you get from reification can be emulated on erased systems (some are admittedly more hackish on an erased runtime, but they should be rare).
> Erasure keeps you honest and prevents you from second guessing the compiler by limiting the introspection you can perform on your code
But the title of the article under discussion is called "The Java type system is broken", after all :)
It would have been possible to implement reified generics while preserving backward compatibility, Neal Gafter had actually a proposal to do just that.
In the end, erasure won simply because it's the superior solution.
Erasure gives you a little less flexibility to express certain constructs than reification allows, but from a type safety standpoint, the two approaches are equivalent.
If you want widen the meaning of "type safe" a bit, I would argue that reification is "less" type safe in the sense that it allows you to perform additional runtime type checks / type casts, which basically means you are second guessing the compiler and invalidating all the type soundness that it has provided you by accepting to compile your code.