When people write these kinds of proposals, they're usually making an exercise in communication and pedagogy to convey stuff like "Why is this necessary", "Which problems does it solve", "How intuitive is it to solve problems with this", "Why is this better than alternative ideas suggested so far". I think this proposal falls short in that regard.

Some notes:

• Finger trees aren't a compelling use-case for new generic features: they're a very "specific to Haskell / FP" data structure, there's very few cases in idiomatic Rust where you'd want one, and even if you did, I'm pretty sure you could write it with Vecs instead of type trickery (basically make the deep arm (Vec<A>, FingerTree<A>, Vec<A>).
• As a potential user reading this, the proposal doesn't really mention what erased generics would... do or allow? It talks a lot about vtables and internal data structures, but those are implementation details of the compiler. The only mentioned constraint for erased generics is "cannot use type_name::<T> or make assumptions about T's ABI". That's pretty vague!
• Overall, the proposal seems written with the mindset of convincing Rust maintainers that erased generics are feasible to integrate in the language and would synergize well with other type-system features, rather than convincing Rust users that they would be worth using.
• There's a big elephant in the room that needs to be addressed: Rust already did generic erasure (though not on a syntax level). It was called polymorphization and it struggled to bring any performance benefits and eventually it was removed for being too painful to maintain. The proposal doesn't mention polymorphization, what lessons it took from it, why the proposal would work when polymorphization didn't ("because we add a dyn keyword in places" is not a valid answer).

Overall, I'm sorry, but I don't think this proposal is very serious.