I don't want to rule out somehow supporting this particular pattern some day, I just think my particular implementation of this idea was flawed. It didn't work in more complex examples, increased the size of the rewrite system by up to 3x even when it wasn't needed, broke some invariants I was hoping to preserve that will allow more optimizations in the future, and I couldn't reconcile it with the minimization algorithm.
Preserving compatibility is always hard when replacing a key component of the compiler like this, especially since generics didn't really have anything like a formal specification and the test coverage was uneven. I spent a lot of time writing new tests and trying to reverse-engineer and understand existing behaviors. I think I've mostly succeeded in this regard, and now that we have a better-defined core we can expand what is supported over time.
For this particular problem, a few of us on the team feel that a better direction for future evolution of the language is to try to eliminate the implied same-type requirements between unrelated associated types of the same name altogether. I know @Joe_Groff is not a fan of this because it can cause coherence problems if unrelated protocols evolve over time.