An LTS release scheme, combined with encouraging libraries to maintain MSRV compatibility with LTS releases, could reduce this friction.
This actually sounds like a good idea. Currently crates are choosing their MSRV all over the place. If we just got a bit of alignment by calling every ~17th Rust release (roughly 2 years worth of releases) an "LTS" release, then crates could be encouraged to keep their MSRV compatible with that release.
But we also heard a consistent shape of gaps [in core]: many embedded and safety-critical projects want no_std-friendly building blocks (fixed-size collections, queues) and predictable math primitives, but do not want to rely on "just any" third-party crate at higher integrity levels.
I think some fixed-size collections and stuff like that would be super nice in core. Something with simple, predictable semantics, just like Vec has (i.e. no optimizations for certain usage patterns, like small string optimizations and that sort of stuff). With const generics working for integers, fixed size collections in core shouldn't even be that hard (it's certainly been done in many crates already).
I don't agree with the comment there. In my mind, the LTS release would not mean anything. It would just be a label on an arbitrary release every couple of years. I feel it could help the ecosystem align on which MSRV to choose, so that you don't have one crate choosing 1.x, another chooses 1.(x+1) and another chooses 1.(x+5). It would be nice if we just sort of agreed that if you care about your crate being used by somewhat older compilers, use the LTS version and consider the implications if your MSRV go beyond that version.
Of course any crate author is free to completely ignore this and choose whatever MSRV they desire. But perhaps a significant amount of authors would put at least a little effort (but not much) in trying to avoid raising the MSRV above the LTS version, just as authors may try to avoid breaking changes and such. It's just a nudge, nothing more.