The root type of a configuration object can not be a sequence

I'm confused. The summary talks about a sequence, but the example shows a mapping.

A sequence:

key:
  - value1
  - value2
  - ...

A mapping:

key:
  subkey1: value1
  subkey2: value2
  ...

A mapping already works at the top-level.

A top-level sequence does not make sense to me. Much rather, it's a sign that configuration objects might be structured too granularly and the sequence should actually be located and merged into another object.

It's a double-edged sword:

By allowing this, we essentially assume that developers have a solid plan about their config requirements ahead of time and for the entire future. — Once you put a sequence at the top-level of (in particular) a $module.settings config object, it will not be safe to add a new top-level key to the config + schema later on. As in the examples here, the sequence key names can be any string that possibly exists.

I doubt that even core has enough of a plan to be really sure. It's perfectly possible that rest.settings needs some additional settings at some point later on. At that point, you either need a more complex module update or migration process, or you're forced to create and use a separate config object, which would have been unnecessary if there wasn't a sequence at the top-level and which is bad for performance.

Even though it could be supported on technical grounds, it is good that we don't support it in my book, since it prevents people from running into a major trap.

Great, so we already have the problem in HEAD:

What if a necessary change for Content Translation module has to add a setting to content_translation.settings?

We'll either have to rewrite content_translation.settings to use a sub-key for the sequence (API-breaking change), or we will have to use a new config object separate from content_translation.settings, even though generic module settings are supposed to live in a $module.settings config object and even though the entire problem could have been avoided by not using a sequence at the top-level in the first place.

I understand that it's technically possible, but not everything that is technically possible is a good idea. :-)

Right, that's why I said that it's a double-edged sword:

If we do this, then there's a good chance that many developers will run into the trap.

If we don't do this, then we're essentially baby-sitting developers. (and yes, without an explicit protection/exception in the existing config schema validation in Config::save(), that baby-sitting is not complete)

IMHO, baby-sitting is a good idea here, since it's going to be exceptionally hard to recover from such a mistake later on.

We don't require schema, but its true that some schema limitations mandate some data structures if you do use schema, eg. a subkey with an identifier value to be used to identify dynamic data types (eg. views plugin ids). I don't have a strong feeling either way whether we should babysit shortsighted developers not using a mapping at the top. I think shortsighted developers will not care about schemas in the first place, and then config is a free form tree, so they will do whatever they like. So not really concerned that we could box them in somehow with an optional system...

Actual code review:

1. +++ b/core/lib/Drupal/Core/Config/Schema/ArrayElement.php
   @@ -114,4 +115,40 @@ public function getIterator() {
   +   * All configuration objects at their root are either of the type
   +   * sequence or mapping which both extend ArrayElement. Enable traversal of the
   +   * schema by excepting a dot delimited key to access nested values, for
   +   * example, 'page.front'.
   

   The first sentence is about config objects, the second is about the method which is very confusing. I only figured this out by reading the patch.

2. +++ b/core/lib/Drupal/Core/Config/Schema/ArrayElement.php
   @@ -114,4 +115,40 @@ public function getIterator() {
   +   * This implements the get() method on the follow schema classes:
   

   following?

3. +++ b/core/lib/Drupal/Core/Config/Schema/ArrayElement.php
   @@ -114,4 +115,40 @@ public function getIterator() {
   +   * To conform with the respective interfaces:
   +   * - \Drupal\Core\TypedData\ComplexDataInterface
   +   * - \Drupal\Core\TypedData\ListInterface
   

   This is confusing, why not implement that interface?

4. +++ b/core/lib/Drupal/Core/Config/Schema/ArrayElement.php
   @@ -114,4 +115,40 @@ public function getIterator() {
   +      throw new SchemaIncompleteException(String::format("The configuration property @key doesn't exist.", array('@key' => $property_name)));
   ...
   +        throw new SchemaIncompleteException(String::format("The configuration property @key does not exist.", array('@key' => $property_name)));
   

   The two messages could use the same English. I know this is pre-existing in the moved code, but since we are doing this...

BTW I looked at config translation and there does not seem to be an assumption about a top level mapping implemented/hardcoded there.

#2212069: Non-English Drupal sites get default configuration in English, edited in English, originals not actually used if translated practically mandates that config objects are sequencesmappings, it will add a langcode key on top level config objects. If they are defined as a sequence and the top level type is not a string, that will break schema validation.

It seems like this is a bit contentious as to whether or not we should do it. Do we have any new perspective on this? There hasn't been any further comments in the past 7 years.

I think this is something we should allow. Probably didn't have any traction because of the existing workaround (as indicated on the OP by alexpott, an example of adding entities: there as root), and we just got used to it.

Last time I missed this was not possible: one week ago.

This is a won't fix at this point. We have a default config_object schema with multiple standard keys, the top-level must be a mapping. Having to group a list inside a key seems like a small price to pay.