This is a discussion I am splitting off from the OpenAPIKit proposal discussion here. It is probably beneficial to skim the previous couple of comments in that thread for relevant context on the subject.
In broad strokes, the question is how to provide a dependable set of core components that might be particularly beneficial for server side Swift development but not (yet) offered by the core or Foundation libraries.
The key benefits (as I see them) of pushing core components into their own packages are (1) code re-use and independent feature/bugfix development and (2) easier interoperability between two packages that use what are functionally equivalent types.
The key drawbacks (again, as I see them) of pushing core components into their own packages are (1) drastically larger and harder to trust dependency trees a la NPM and (2) differing opinions (all valid) on what capabilities or spellings should be used within such core components could increase the prevalence of name conflicts with SwiftPM packages.
With that, and with no intention of closing off other avenues of discussion in this thread, I had one idea for how to strike a compromise allowing the SSWG to endorse certain implementations of common core dependencies over time and to be driven by emerging demand as more libraries are accepted into incubation.
What if the SSWG endorses a "common server-side core" package with different products for each core component it accepts in the same fashion as it accepts libraries into the incubation process. This would necessitate a more opinionated stance -- as an example, only one particular implementation of an OrderedDictionary would be blessed with inclusion into the common core package. This would reduce the proliferation of bite-sized packages while still offering piecemeal inclusion because of the independent products offered by the package (you would import OrderedDictionary instead of import CommonCoreLibraryName).
A point central enough to my suggestion to bear repeating is that inclusion of a new type in this package would not be motivated simply by a pitch thread that the community liked the sound of, but more restrictively limited by the repeated occurrence of such a core component in other libraries being considered by the SSWG. Over time, subsequent releases of libraries in SSWG incubation could switch out their independent implementations for those in the common core package.
The parallels between the structure of this package and that of the Preview Package for the standard library do not escape me, but I do see this as a separate thing conceptually because I believe some components are particularly germane to server side development and not therefore good or likely candidates for ever being included in the standard library.