The short answer is that we do not (yet) have a complete plan on how to best replace swift-corelibs-foundation usage with swift-foundation. There are some challenges that will need creative solutions and collaboration in the Swift-on-server community. You have identified a few of them. In order to get there, though, we're working incrementally.
Right now we are building the fundamentals that we need in order for the package to be a viable replacement in the first place:
- Develop a high-quality Swift implementation of our most important API
- Use that Swift implementation in the most widely-deployed version of Foundation (iOS, macOS, et. al.).
- Add new Swift API in collaboration with the community (e.g. the new Calendar API pitch).
As touched on in the other thread, we are well on our way. The code in our GitHub repository has indeed shipped as part of iOS 17 and macOS Sonoma. That includes our new, dramatically faster implementations of JSONDecoder and Calendar. Shipping as part of a major OS release is also an incredible stress test for these implementations. They are in constant use on millions of devices in a wide variety of configurations.
The reason we have not tagged a release of the package yet is simply because we are being conservative about declaring a 1.0 as ready for use. There are a few more key APIs which we need in order for the package to be broadly usable on Linux. On Darwin we can fall back on Objective-C or C implementations to fill those gaps, but for the package we want the implementation to be as much Swift as possible.
Thanks for the questions, and I hope this helps to clarify.