Apart from the fact that I do not like packages stopping to build when updating the compiler

This is not the fault of time.

updating time to 0.3.36 would require raising MSRV to 1.67, which I do not like.

Why do you need an MSRV that is more than 18 months old? Very few crates have policies that extend that far back (with chrono not having a policy at all, mind you).

Apart from the fact that I do not like packages stopping to build when updating the compiler

This is not the fault of time.

I'm sorry, I was indeed under the impression that this was the fault of time. Rereading your post (time-rs/time#681 (comment)), I see that this does not seem to be the case after all. I hope that you accept my apology.
Still, I do not understand how adding a new trait implementation to the standard library could break your code. I thought that Rust's coherence rules prevent such breakage? If you can enlighten me on this point, I would be very interested.

updating time to 0.3.36 would require raising MSRV to 1.67, which I do not like.

Why do you need an MSRV that is more than 18 months old? Very few crates have policies that extend that far back (with chrono not having a policy at all, mind you).

A colleague of mine who was not into Rust at that time once tried to install one of my Rust programs on Debian and failed because his system-installed compiler was too old. I just checked now, and the rustc shipped with stable Debian is 1.63. So I'm trying to preserve MSRV as long as it is not too much effort.

Still, I do not understand how adding a new trait implementation to the standard library could break your code. I thought that Rust's coherence rules prevent such breakage? If you can enlighten me on this point, I would be very interested.

Essentially, the code I had written relied on the fact that the return type of .into() could be inferred. Type inference is something explicitly permitted as breakage. With the addition of IntoIterator for Box<[T]>, this was no longer the case. This specific instance of breakage was caught months ago, which is why a patch was merged and released in April.

A colleague of mine who was not into Rust at that time once tried to install one of my Rust programs on Debian and failed because his system-installed compiler was too old.

I honestly don't understand why they even bother shipping a version so old (it was released two full years ago). rustup is always the recommended way to do anything related to Rust, in my opinion.

I honestly don't understand why they even bother shipping a version so old (it was released two full years ago). rustup is always the recommended way to do anything related to Rust, in my opinion.

I also use rustup, but from my own experience with people who are just trying Rust, the majority first tries to install a Rust toolchain using their package manager. And that's only one case of people that I know about who might be stuck with an older Rust toolchain. There might be others. Keeping MSRV low means to cater to the needs of these.

Essentially, the code I had written relied on the fact that the return type of .into() could be inferred. Type inference is something explicitly permitted as breakage. With the addition of IntoIterator for Box<[T]>, this was no longer the case. This specific instance of breakage was caught months ago, which is why a patch was merged and released in April.

Thanks for your explanation, @jhpratt!