This is rather confusing, so maybe deserves a comment - maybe something like this?

// The resulting config objects should include the effect of the base config object 
// with the `extends` key removed so we forward it along as the last object, 
// unless it would be a noop or global ignore

Feel free to word this better than I have 🙂

I do agree it is confusing, but I can't really think of a more elegant way to express it.

It's possible it may be more readable if the logic wasn't so condensed into that one array such as:

const configArray = [...];

if (
  Object.keys(config).every(key => ['name', 'files', 'ignores'].includes(key))
) {
  return configArray;
} else {
  return configArray.concat(config);
}

But that may also be too verbose, so not sure.

Does the comment sound alright?

... if the logic wasn't so condensed into that one array

Feel free to change this! 🙂 TBH I actually prefer mutating the array for a case like this.

const configArray = [...];

if (
  !Object.keys(config).every(key => ['name', 'files', 'ignores'].includes(key))
) {
  configArray.push(config);
} 

return configArray;

Does the comment sound alright?

My nitpick would be that, as written,

    // The base config should not be included in the final output if it
    // consists of only metadata keys (i.e. properties that do not affect the
    // final ESLint configuration object)

makes it sound like it would be a harmless noop if such a config were included in the output, and we're just doing this cleanliness, but the real reason we're here is that it's actually a harmful operation in the case of global ignores. So if there's a way to convey that 🤷

Coming from #10755 (comment), probably best we do this as

function isPossiblyGlobalIgnores(config) {
   Object.keys(config).every(key => ['name', 'ignores'].includes(key)
}

const configArray = [...];

if (
  !isPossiblyGlobalIgnores(config)
) {
  configArray.push(config);
} 

return configArray;

I'm thinking we should add logic to handle this type of case too?

  it('does not create global ignores when extending empty configs', () => {
    expect(
      plugin.config({
        extends: [{ rules: { rule1: 'error' } }, {}],
        ignores: ['ignored'],
      }),
    ).toEqual([
      { ignores: ['ignored'], rules: { rule1: 'error' } },
      // Should not create global ignores
      // { ignores: ['ignored'] },
      // { ignores: ['ignored'] },
    ]);
  });

Is now handled

...
expect(configWithIgnores).not.toContainEqual(
  // Should not create global ignores
  { ignores: ['ignored'] },
);
...
expect(configWithMetadata).not.toContainEqual(
  // Should not create configuration object with no non-metadata keys (noop config)
  { files: ['file'], ignores: ['ignored'], name: 'my-config' },
);

I might be misunderstanding, but it doesn't appear that this case has been handled? To be clear, the part that I'm trying to highlight is that in the extends list, there's an empty config object, which will resolve to a { ignores: ['ignored'] } if we're not careful.

... if the logic wasn't so condensed into that one array

Feel free to change this! 🙂 TBH I actually prefer mutating the array for a case like this.

const configArray = [...];

if (
  !Object.keys(config).every(key => ['name', 'files', 'ignores'].includes(key))
) {
  configArray.push(config);
} 

return configArray;

Does the comment sound alright?

My nitpick would be that, as written,

    // The base config should not be included in the final output if it
    // consists of only metadata keys (i.e. properties that do not affect the
    // final ESLint configuration object)

makes it sound like it would be a harmless noop if such a config were included in the output, and we're just doing this cleanliness, but the real reason we're here is that it's actually a harmful operation in the case of global ignores. So if there's a way to convey that 🤷

I might be misunderstanding, but it doesn't appear that this case has been handled? To be clear, the part that I'm trying to highlight is that in the extends list, there's an empty config object, which will resolve to a { ignores: ['ignored'] } if we're not careful.