I’ll admit I dont fully understand the rfc on the implementation level, so I may be off the mark here:
I think this is best explained with microvm. Looking at all those hypervisors, it’s safe to reason this could be abstracted into a “hypervisor” contract. However, if you have a machine that requires a hypervisor with virtiofs support, only certain “virtiofs capable” “hypervisor” providers can accommodate that. “Virtiofs capable hypervisor” would be the subset you want, but we can’t manually create a subset for every possible combination of hypervisor features.
Normally I’d use unions as well, but how do we describe a particular contract that can only exist when another is present? I.e. a union between “hypervisor” and “virtiofs capable” is great, but “virtiofs capable” can only exist if “hypervisor” already exists. I.e. it sounds to me like we need a flexible system to validate that a requester is requesting a valid contract, and that a producer is producing a valid contract, which to me sounds like we need contracts to come with rules to determine how they can be combined, excluded, or selected.
The first sulotion I’d reach for is feature flags, but maybe the existence of certain optional keys could be flags themselves? If no additional options are needed than they can just be keys to empty sets.
Alternatively contracts could come with a list of validation functions, and a special set of contract merging function (union, intersection, negation, and derived functions such as conditional and disjoint union) could be created which do the job on their name, but always merge the validation function list, which in turn can generate warnings or errors.
We also need to consider disjoint unions. For example Attic can use the local filesystem xor an s3 bucket, but not both at the same time.