Too strict schema for system.mail:interface

So what is stored there? Are all of those settings for sure?

@berdir pointed to MailManager::getInstance():

   * The selection of a particular implementation is controlled via the config
   * 'system.mail.interface', which is a keyed array.  The default
   * implementation is the mail plugin whose ID is the value of 'default' key. A
   * more specific match first to key and then to module will be used in
   * preference to the default. To specify a different plugin for all mail sent
   * by one module, set the plugin ID as the value for the key corresponding to
   * the module name. To specify a plugin for a particular message sent by one
   * module, set the plugin ID as the value for the array key that is the
   * message ID, which is "${module}_${key}".
   *
   * For example to debug all mail sent by the user module by logging it to a
   * file, you might set the variable as something like:
   *
   * @code
   * array(
   *   'default' => 'php_mail',
   *   'user' => 'devel_mail_log',
   *   'contact_page_autoreply' => 'null_mail',
   * );

So it is indeed a list of arbitrary strings. The patch seems to be good. The reason it was not caught before is because we only had a phpunit test for this, no integration test.

+++ b/core/modules/system/config/schema/system.schema.yml
@@ -333,12 +333,11 @@ system.mail:
       label: 'Interface'
...
+          label: 'Individual interface'

I would call them 'Interfaces' and 'Interface', that is what we do elsewhere. We don't need to change the key names, but the labels we have more free control over :)

Interface is a pretty weird thing anyway, not sure what that means exactly, in the past, we stored class names (implementations, not interfaces) and what we are storing there now are plugin IDs.

Not sure what to do about that with the labels, having something completely different in the labels is also weird.

LOL I will fix that individual thing in a new version later :D It will need 1 line moved...

I think this is good to go.

Not sure if it's just normal, it's at breaking the ability to use this in tests, which means it's blocking contrib module tests.

I think this is a major bug.

This issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 2a7aaa0 and pushed to 8.0.x. Thanks!