You did remind me of one more that I meant to write up, but then forgot:
- "Extensible Product Types": Right now, SwiftPM only supports a very limited set of product types (executables, libraries, tests). In practice, the world contains many more specialized kinds of product types that would often benefit from having explicit syntax in a Package manifest, but SwiftPM cannot reasonably expect to encode all of these. You can imagine this applies to Apple product types (like a traditional framework, or app, ro other things with an Info.plist), but the universe is much much larger (think of Photoshop plugins, or domain-specific framework helper tools that must follow a particular convention, even things like a Clang AST plugin very close to home). Some of us on the SwiftPM team have often hypothesized about a potential design where packages themselves could vend new product types (similar to the concepts around extensible build tools), so that the owners of such product types could expose a custom sort of PackageDescription extension to allow clients to define their product type using whatever natural APIs made sense).