Unfortunately, in the Rust/Cargo ecosystem, 0.x version doesn't mean much, and Cargo's rules for 0.x are different from semver rules for 0.x. There are major widely-used crates that are on 0.x ( libc, time, log, futures). Plenty of 0.x crates are de-facto mature and stable. libc probably won't ever have a 1.0.0 release, because it's so stable and widely used it's not worth the churn.
All crates tend to bump MSRV in minor releases. It's not limited to "experimental" ones. In the ecosystem there's simply no agreement about this issue, and MSRV-breaking wins just because of the network effect, e.g. if you have 100 transitive dependencies, and 99 crates agree to bump MSRV only on major version, but 1 doesn't agree, then your project is still broken. IMHO this situation is hopeless. It's not even worth trying to preserve MSRV beyond last 3 Rust releases.
I know packaged Rust is problematic. Debian's Rust is the worst one. It practically doesn't work with anything from crates-io. It is and will remain useless until either Rust or Debian change their release policies, and they won't, because each project has a good reason to be this way. I don't see any way around this other than to keep warning users to never ever use Debian's Rust. At least after 1.56 (in Debian in ~2023), Debian users will get a clear error messages about their outdated Rust rather than odd compilation breaks or false "needs nightly" errors.
It's not worth trying to fix these MSRV breaks by locking dependency versions, because that causes even bigger issue for all Rust users: conflicts. Cargo allows only a single semver-major version per dependency. If you use =1.0.1 and someone else uses =1.0.2, the project won't build at all. Even if you try to be flexible and use >=1.0.0. <=1.0.2, then any crate with 1.0.3 will break the project too, and not just for old Rust versions, but for everyone. We've been there when some crates had broken releases. We've been there with zeroize. We've been there with bincode vs byteorder MSRV fight. You can still "pin" dependencies in your private projects and binary crates, but please don't do that in libraries used by others. It only ends up causing even more breakage.
I think currently the best chance of supporting older Rust versions is -Z minimal-versions which could work if people stop putting imprecise dependency versions in their crates. If you specify serde = "1.0", then -Z minimal-versions will roll it back by 160 releases, and 5 years of development, and your crate will certainly be incompatible, because serde crate is not following semver. Same goes for cc, anyhow, syn and a few others non-semver crates. OTOH if you specify new versions, even very latest ones, then -Z minimal-versions will work, and Cargo's dependency resolution will figure out a set of crates it can use. If your deps are too new, then Cargo will just use older version of your crate, which had previously-latest versions.
So paradoxically, to support old Rust, the best way is to bump dependency versions.