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.