ibizaman: I definitely agree on the fact that we need contracts, at the very least for cases where we have multiple implementations. However, I do not know what you attempted to do with mkOption and I want to suggest a very simple idea instead: “options are already one form of contracts”, there is no need to add an additional layer on top of mkOption, and most people should never look into mkOption.

On the other hand imagine the following:

config.contracts.reverse_proxy.<name> = { … };

This could be what is targetted by requesters which are looking for having a reverse proxy.

But how does these contract get honored? We could add an enum type, where each implementation provide a new entry in the enumerated type of the contract as a provider. If the provider is selected for the given contract, then we can forward the configuration to the provider option.