Well, you can't do that because of coherence. Coherence means an implementation of a given trait for a given type must be unique. In your example, you provide a Display implementation for every type implementing MyError. However, Display is not under your control, as it is part of the standard library. In fact, there are already tons of implementations of it.
Now, suppose you implement MyError for a type that implements Display itself. How should the compiler know, which implementation to pick, when you call the method?
This is why there is the concept of coherence. There are some languages that work around this in different ways. In Rust, you are stuck with this limitation though.
Practically, it does not seem like your MyError trait adds any more value than Display does on its own. So I would simply suggest to get rid of it and use the standard library's abstraction directly. If you want to go through with the current approach, you need to use some kind of wrapper type, on which you can implement Display. Since you have control over the wrapper, coherence does not apply in that case.
Actually I already got rid of the Display impl, but I was still interested, why it actually failed.
Still I find the error message especially confusing. I already guessed something in this direction, but I can still not see on which type the conflict actually occurs. The compiler says &_, which I find confusing.
Not sure where it’s documented but when you define a trait the compiler generates a "companion" trait object by the same name. That’s what allows you to define inherent methods on trait objects of that trait type, ie:
trait Foo {}
impl Foo {
fn bar(&self) { ... }
}
Now bar is available on all Foo trait objects (eg &Foo, Box<Foo>).
Similarly, you can implement traits for this trait object.