Rust’s release cadence is 6 weeks not 6 months.

My bad, I thought it was 6 months. Okay, a bit too often, but no reason why debian folk can't update it more often than it is now.

> latest rustc always able to compile older rust code.

That is not true. Adding any public method to any impl can cause existing working code not to compile, and Rust adds new methods to the stdlib all the time.

I don't believe this is correct. I have not once seen a new method being added to stdlib that causes code to not compile. And ABI concerns are a non-issue since Rust is statically linked.

It is correct. For example, this code (admittedly a contrived example, just to illustrate the point) compiles in 1.82 but not in 1.83:

  trait OptionExt {
      fn get_or_insert_default();
  }
  
  impl<T> OptionExt for Option<T> {
      fn get_or_insert_default() {}
  }
  
  fn main() {
      Option::<()>::get_or_insert_default();
  }

The reason is that `get_or_insert_default` was added to the stdlib in 1.83, and takes a different number of arguments, so it clashes with the user-defined one here.

Interesting, I would think that having OptionExt in scope would make it clear which method to use.