The outcome of T359193 is to support required in JSON schemas but loosening the validation step to not take it in account for the top level properties of an schema while reading a configuration. But using it regularly on API submissions and writes in general. This is to circumvent the indirection of a configuration not being available at a given time and making the system unrecoverable from that situation.

Open questions:

In T359193#9656814, @Urbanecm_WMF wrote:

This approach is similar to the concept of validation warnings (blocking saving, but not reading) and validation errors (blocking everything), which we introduced in GrowthExperiments. Back then, it was done as part of T312576: Structured mentor list should validate the maximum length of a mentor message (see patch for additional context). This makes me wonder: How should we implement the validation warning system in CommunityConfiguration, now that we have fully-blown JSON Schemas? Should we have a generic concept to mark certain validation rules as "soft" (ignorable on reads, but enforced on writes)? If so, is there a reasonable JSONSchema extension we could use/create to record this sort of decisions within the schema itself? How can we make ReflectionSchemaSource read declarations that are CommunityConfiguration-specific? Is that even a good idea?