Should configurations like `static` and/or `shared` be blessed by the specification?

In the sample CPS in the documentation, we have the following:

    "sample": {
      "Type": "interface",
      "Configurations": {
        "Shared": {
          "Requires": [ ":sample-shared" ]
        },
        "Static": {
          "Requires": [ ":sample-static" ]
        }
      }
    }

I suspect having components with a "Shared" and a "Static" configuration (perhaps with different configuration names, like "archive" and "dynamic" or something like that) is going to be pretty common. What do you think about having the specification recommend (for example) Shared and Static as the blessed names for this kind of configuration?

I believe Conan blesses shared in a similar way, from https://youtu.be/kKGglzm5ous?si=eC7gMU9_sDfk3d_Q&t=2810

(...) The shared option has become a standard, and if some package defines the shared option, the package type is automatically deduced.

The use-case I have in mind is the following: users may want to indicate their build tool to always prefer static libraries for their dependencies if they are available. The build tool then, when traversing the CPS dependency graph, could then choose to always choose a "Static" configuration if one is available, so as to honour the user's intent. This only works if people always use the "Static" configuration name for the static archives of their libraries but falls apart if the creators of the CPS files decide to call their static configurations other names, like "archive", or "static-archive", or "staticArchive", or whatever else. Having a blessed name that we encourage CPS creators to use alleviates this problem.

Does this sound about right? Or am I misunderstanding how you expect these CPS files to be used?

cps-org / cps

Should configurations like `static` and/or `shared` be blessed by the specification? #26