The canonical example is when a library has extended a standard trait -- adding a new trait method can cause errors due to ambiguity.

Say you had the following code:

  mod rs_std {
      pub trait StdGreetings {
          fn hello(&self) { println!("Hello!"); }
      }
  }

  use rs_std::StdGreetings;

  trait MyGreetings: rs_std::StdGreetings {
      fn good_morning(&self) { println!("Good morning!"); }
  }

  struct MyGreeter;

  impl StdGreetings for MyGreeter {}
  impl MyGreetings for MyGreeter {}

  fn main() {
      let g = MyGreeter{};
      g.hello();
      g.good_morning();
  }

This is totally valid, it'll compile, and it's not an unreasonable use case to want to extend standard traits like `io::Write`.

The problem is that a newer version of the standard library might have this:

  pub trait StdGreetings {
      fn hello(&self) { println!("Hello!"); }
      
      fn good_morning(&self) { println!("Good morning!"); }
  }

And now that existing code will fail to compile.

The Rust team's answer to this is "crater runs", where they build the current versions of all packages on crates.io with the new compiler to predict the ecosystem impact of a potential change.

https://github.com/rust-lang/rust/issues/88967: they've delayed adding an `Iterator::intersperse()` method to the standard library, since it conflicts with the `Itertools::intersperse()` method from the popular `itertools` crate.

It is possible. If you implement a trait with a function “foo” on some stdlib type, then “foo” is added to the type’s inherent impl, the inherent function will now be called instead of the one in your trait when doing x.foo()