This is interesting work, but I think it's important to clarify why this is happening here:
There is a difference between retroactively conforming a protocol P to another protocol Q, and conforming all types which conform to protocol P to another protocol Q. This is the point I raised above many months ago.
What you have done here is implemented the second feature, which is both possible to implement and adds very interesting possibilities, but as though you were implementing the first feature, which (as the Generics Manifesto documents) is impossible to implement both completely and efficiently, and used its syntax extension P: Q.
The second feature is a specific case of parameterized extensions (and called out in the draft proposal specifically as a future direction) that would be spelled extension<T> T: Q where T: P (or more succinctly, extension<T: P> T: Q). When we bring over the simplified spelling of opaque types to generics, then this could also be spelled extension some P: Q.
When you clarify conceptually the distinction between the two features, it will become obvious why this crashes: recall that the existential type P doesn't actually conform to P, so after implementing the second feature, it likewise does not conform to Q and doesn't have its default implementations. If we ever get around to clarifying the distinction between protocols and existential types by spelling the latter any P as some have suggested, then this would become immediately obvious: extension some P: Q would not be the same thing as extension any P: Q.
It would be wonderful to have the feature you've actually implemented in the language. Since it is a specific case of parameterized extensions, and @Alejandro has already written a draft implementation and draft proposal of that feature but not extended it to include the feature you've worked on, combining forces would produce a consistent and usable result without the problem you recount here.
Bravo on sticking to the effort!