Defining the Rust 2024 edition

Ant any given moment, it is. It only needs to consider its own set of packages. Yes, that set changes over time, but the point is just that the Rust libraries can *serve the rest of the distro* using explicitly monomorphized versions of their generic types/functions. (Locally installed consumers, of course, would need to revert to the current status quo unless they happen to need variants of the generics that are already monomorphized in the distro.)

> Do you want to recompile all the libraries whenever a new package is added?

No. I believe that with what I suggest, you'd only need to recompile libraries for which said package requires new concrete variants of generic types/functions, or new macro expansions. That's certainly better than the "rebuild everything" world that is today.

> And quite likely, the generics are instantiated with types that are defined by the consumer of the library. Otherwise, there is not much value in having generics on the public interface anyway. Why should this code that is only relevant to the consumer be in the shared library?

Because it's library code. And hopefully there'd be significant overlap between consumers.

> It would be infeasible anyway, as you would need the code of all consumers to actually build the library.

This is exactly why it's important that distros are closed systems. You *can* extract all that information from all consumers, because you have an explicit set of consumers.