Love to see a problem from the frontline of computer science as an actual practical problem solution to which would greatly benefit languages' semantics.

Regarding conflicting impls in crate_c and crate_d: what is wrong with Haskell's approach of grading impls by their specialty (e.g. Show Int is more specific than Show a so prior instance would be used if matches) and only throwing an error if it's ambiguous to the compiler which instance to use?

I see that this is not sufficient, since crate_e can't do anything about conflicting impls in crate_c and crate_d. Having to explicitly import impls does not spark joy. The problem is more convoluted than I thought!

I'm very interested in this topic since I'm working on a language that features traits and thus have a chance to "fix" it.

P.S. found another good article on this topic: https://www.michaelpj.com/blog/2020/10/29/your-orphans-are-f...

"Regarding conflicting impls in crate_c and crate_d: what is wrong with Haskell's approach of grading impls by their specialty"

You can still get surprising errors later in crate_c and crate_d when crate_e adds something, which is suboptimal.

I'm not saying all solutions are equally good or bad, just that there isn't a known perfect solution yet. If you accept the principle that "Writing some more code into module E shouldn't cause new errors to appear in C and D", which is a reasonable thing to want in a system, then this isn't a perfect solution.