[JoshTriplett]

The gccrs developers have talked at length with Rust developers towards the same aim: they don't want to create fragmentation either. Among other things, the gccrs developers have said in multiple places both public and private:

- They aren't going to fork or extend the language; they'll work with the normal Rust language evolution process.

- They're treating rustc as the reference for correct Rust. This doesn't mean there can't be bugs in either rustc or gccrs, and rustc will deeply appreciate bug reports found through this level of inspection of its behavior, but nonetheless this is a stated goal of the gccrs folks.

- They plan to explicitly provide messaging, potentially even in compiler error messages, to the effect of "if gccrs doesn't compile a crate that does compile on rustc, that's a bug in gccrs, not a bug in that crate; do not report it as a bug in that crate or ask crate developers to work around gccrs limitations".

So, I think the gccrs folks are doing everything they can to avoid fragmentation, short of the project not existing at all.

[3836293648]

They don't have to extend the language to create fragmentation. Being far enough behind rustc is enough

[cesarb]

> Being far enough behind rustc is enough

But rustc itself can be far enough behind rustc, as the MSRV debate shows.

[masklinn]

You can already do that. Some libraries wilfully restrict their MSRV for backwards compatibility or distro compatibility (e.g. Debian stable provides 1.48).

[JoshTriplett]

No argument there, but I think the third point helps address that somewhat.