How are build systems supposed to choose configurations of transitive dependencies?

Say we have:

* A package `A` with a component `A`. `A`:`A` has a `Requires` on `B:B`.
* A package `B` with a component `B`. `B:B` has two configurations, `B-config1` and `B-config2`.

And now say that the user of a CPS-compatible build tool wants to build their project against `A:A`. The build tool will have to transitively process `B:B`, and will have to choose whether it consumes the `B-config1` configuration or the `B-config2` one. How do you envision that tools should do this? I can think of three different approaches:

* **The user of the build tool explicitly specifies the desired configurations even for their transitive dependencies**. So the user, somewhere in their build config, would have to specify "For `B:B`, I want to use `B-config1`". This is not very scalable, specially as dependency trees become deeper and deeper. For deep dependency trees, the user might not even know about `B`, so they wouldn't necessarily be capable of choosing between `config1` and `config2`.
* **`Requires` in components should explicitly specify their desired configs**. `A:A`, instead of `Requires`ing `B:B`, would explicitly require `B:B@B-config1` (which is already permitted by the specification). This is an expectation we would be placing on packagers.
* **Packages only define configurations with semantics that are well known to the build tool**. When the build tool finds `B-config1`, it doesn't know what `B-config1` means, so it cannot choose for the user. However, if the configurations were just `static` and `shared`, the build tool could choose itself to use `static` if the user expressed a preference for static linking. Build tools could support other well-known configuration names, and packages and components would be created that provide only such well-known configurations. This would imply a contract between package manager/packagers/build tools about what configuration names have well-known semantics (like `static`, `shared`, ...)

The specification doesn't necessarily have to prescribe one of these three options. The current version allows for the three, and it would be a matter of how the ecosystem grows around it. Perhaps the three can coexist for different use-cases.

But maybe you already have something in mind, and it could be useful to provide guidance in the site.