Regression: Third party settings for simple config due config schema validation

A bit more digging:

Core's system.schema.yml does not include a third_party_settings key in the system.site section.

ConfigFormBase::validateForm() calls $typed_config->validate(), which prevents the form from submitting.

Hacking a blanket third_party_settings: { } key into core's schema file would at least allow a form submitting the values, but it still would not use my module's schema types or constraints.

Copying my entire schema into the core file would work.

For reference, my module's schema file:

system.site:
  third_party_settings:
    seasonal_paragraphs:
      type: mapping
      label: 'Summer season'
      mapping:
        from:
          type: string
          label: 'Summer season start'
          constraints:
            Regex:
              pattern: '/^\d{4}-\d{2}-\d{2}$/'
              message: "%value must be a date in YYYY-MM-DD format."
            NotNull: []
        to:
          type: string
          label: 'Summer season end'
          constraints:
            Regex:
              pattern: '/^\d{4}-\d{2}-\d{2}$/'
              message: "%value must be a date in YYYY-MM-DD format."
            NotNull: []

My current workaround is creating a dummy form and disabling all form validation (override validateForm and don't call parent::validateForm()). I can even use '#config_target' => 'system.site:third_party_settings.seasonal_paragraphs.to' for form building... as long as I don't validate it...

I don't really get the use case for adding third_party_settings to simple config.

For config entities, it's because you want extra data specifically in THAT entity -- that view, or field, or formatter.

But for simple config, putting some settings in your own new simple config is functionally the same as extending a core or config simple config.

third party settings on simple config was never supported. Automated tests have defaulted to validating config schema for years and would have failed on this.

Per #4, you can alter an existing form and store your config in your own simple config, see for example automated_cron in core: automated_cron_form_system_cron_settings_alter()/automated_cron_settings_submit().

Use case for 3rd pary simple config is per-theme config settings. E.g. Tailwind JIT → module. Theme config is simple config.

2nd reason is it was quick and easy. The amount of boilerplate code required foryour own form is massive, compared to hooks if your module has just a very minimalistic one field config. It is often also is much better UX, if you add your setting to a form your users already know and thematically fits, instead of one more page in the config area.

Yes, theme config is a bit of an edge case, but doesn't change the fact that third party settings never were supported, it just wasn't validated strictly enough. You can store it in your own config, keyed by the theme or a config file per theme, both is possible.

The example I referenced to is a form alter, not a separate form, nothing has to change in the UI for users.