Haskell's type classes are very different from Rust's generics in some important details.
Haskell in general feels a lot more permissive, worryingly permissive at times, when it comes to implementing type classes for types. Meanwhile, at the same it has seemingly arbitrary limitations, for example: creating associated types or dealing with multiple typeclass constraints (the equivalent of Rust's trait bounds) is a real pain.
From what I can tell, this paper tries to bolt Coherence onto Haskell, which is a noble goal, but I don't think Rust needs that, since it was designed with coherence in mind from the ground up.
(What some people seem to be asking for at times is exactly the reduction or at least the loosening of coherence rules, and that is partially addressed by specialization. That sounds undesirable to me for reasons I'm not going to re-iterate here, but it is a significant change that has come up in the past.)
Although probably more of a change even from the above paper (though I'm not sure), Idris has an approach that seems to work: there are default instances for classes available in some cases, but there is a way for the programmer to specify the instance being used within a context (e.g. a particular function, iirc).