plugins with derivers aren't listed correctly

It's because ListPlugins::execute() builds an array keyed on the value of $plugin_definition->getId().

Looking at the site where I've just been breaking my head, some modules (facets) have ids that include base_id:derivative_id however others (ctools, system, views) return just base_id.

Now I'd actually like to know, should ctools and views, system (both core) be returning full derivative id from getId() not the base plugin id? Is facets more correct?

Anyway the key doesn't need to be the result of ::getId() because it could just use the key from ::getDefinitions()

If a plugin is derived from another, its ID should by default contain its base ID (the ID of the base plugin specifying the deriver), and its derivative ID (something unique within the collection of all plugins derived from the base plugin), creating a unique plugin ID. If a system wants to deviate from this and still maintains uniqueness, that is fine, but in this case you just ran into #2458769: Derivative plugin definitions contain base plugin IDs instead of derivative IDs, which is why I am closing this issue as a duplicate.

Is there any reason not to apply the patch though? The key will be unique for the list that needs to be created, thus showing all plugin derivatives correct id or not.

Keys did not use to be documented as part of public APIs, which is why this was never done in the past. Now they are, so you're right about applying the patch. It won't fix this problem everywhere though, for instance when definitions are retrieved through DiscoveryInterface::getDefinition().

OK I'll add it to needs review: For this patch for this project, just to fix the lists here, at least while core gets its act together. It also makes it pretty obvious that they do return the same id, so it gives fair warning that there might be problems elsewhere ;)

Can you think of anywhere else in this project that it's making lists keyed on the getId(), where it could use the key, to ensure they're all available?

There are 10 non-test usages of \Drupal\plugin\PluginDefinition\PluginDefinitionInterface::getId() of which 5 could potentially be converted to using the plugin IDs retrieved from the keys from DiscoveryInterface::getDefinitions()'s return value. The other usages work with individual definitions, and in those cases the ID can only be gotten from the definition itself.

I do want to urge you to chime in in that core issue. It's a real bug that breaks things, and we need some good insights to move it forward, because we can no longer break BC.

#2458769-35: Derivative plugin definitions contain base plugin IDs instead of derivative IDs now contains a working patch for Drupal core.