@Michael_Ilseman would you be able to expand on the reasons for wanting to include it in the toolchain? I share the concerns with many of the others in the thread about the speed of change if the package were to move to the toolchain.
As far as I read it, one of the desires was to allow other packages in the toolchain to use System but there’s nothing stopping that from happening now, in the same way that collections is used by Foundation right? Or are you wanting to expose system types in Foundation’s APIs?
Regarding platform parity, I share the pain with this. But system was never designed to have cross-platform parity and explicitly calls this out in the README. So even if the imports are fixed, that would still end up with complicated code at the call sites. (And don’t get me started on FoundationEssentials).
One other issue will be what to do when someone is currently depending on System as a package then tries to build with a toolchain that includes System? There is precedent for this, with Testing but it has complicated things like adoption in other libraries, like Swift Syntax. I think these edge cases need to be explored before a decision is made.
Given the Swift version support for Swiftlang is current + previous 2 versions, I would prefer to see the API expanded and settled before locking it to toolchain releases and the pain that will introduce. I however see no reason as to why the package can’t be sponsored for the swiftlang org, or be depended upon by Foundation.
I also agree the documentation tooling needs to be improved to expose platform support, but this is a wider issue for the ecosystem as well