Installation fails for modules providing config entities with a bundle plugin

Ok, let's make sure that we have the same understanding of terminology.

What is a bundle? For me, it is a group of entities that have the same behavior in some way. This may be by implementing a certain interface (via bundle classes supported in recent versions of Drupal core), or by having the same fields, or by having the same configuration options. These determine the behavior of the entities that belong to the same group (bundle).

The Group module provides the Group Enabler plugin type that determines certain aspects of the behavior for Group Content Types that are configured to use them. That includes certain configuration, access control, and more. Therefore, these are bundles of group content types i.e. bundles of config entities. Whether you call them "bundles" or not is not the point.

To be technically accurate, at the end of the chain and through the config entities they configure the behavior of the content entities. Still, this doesn't change the fact that they group config entities together.

Back to your point that "these are not bundle plugins"; I think the issue here is that the most common case is that you bundle content entities together and therefore we have an established terminology for that. We want to use another term for the case I'm describing? Totally open to that, even though I don't see the point for this. To me, and probably others, it's totally fine to call them bundled config entities.

From a practical perspective, there are also many similar issues and needs that are raised for both bundled content entities and bundled config entities - like the one in the issue linked in this comment - and it would make sense to refer to them and address them in the same way.

I'm writing down my thoughts on these and I will then let it rest. Sorry for making it long, it helped me process all information and make a decision on my side.

IMHO that's for historic reasons it existed there before content/config entities as separate things were a thing

I don't know if it's there for historic reasons - could be, but it's not just that. hook_entity_bundle_info_alter makes available config entities as well for defining bundles on them including custom bundle classes as per Introducing bundle classes - either that's a bug or that's a feature - while EntityTypeInterface (that holds config entity definitions as well) define API methods that allow config entities to be bundleable as well.

IMHO, bundles in general but more importantly this feature is only for fieldable entity types, that's their purpose.

Bundles in general provide a range of functionality and not just fields - including different configuration, and even custom APIs - via bundle classes - that could define any functionality that might have nothing to do with fields. From the link above: "Entity bundles are essentially business objects, and now they can declare their own class, encapsulating the required business logic.". The most common use case is to use bundles to define fields per bundle, but this does not mean that the purpose of bundles is just that.

you want to look at \Drupal\Core\Entity\EntityWithPluginCollectionInterface

The difference between that and what I'm trying to do (and the bundle plugin pattern in this module) is that it is a way to handle potentially multiple plugins that could have different meanings for the entity. The bundle plugin is something more specific, it is the primary and standardized way to determine the behavior of an entity. A config entity is a plugin anyways, it could be handled that way as well; but it's not because by convention it is given a special place and meanings in the system and we make it easier for developers to work with it.

Drupal core doesn't support bundles on config entities. Only content entity types support bundles.

Drupal core provides the basis for support - see comments above, but it doesn't support it as a fully developed feature. And it probably shouldn't, the same way Drupal core does not support bundle plugins. This is not the most common use case and it may not gain traction to justify development and maintenance. Even though if it were to be used in multiple places in core, such as in blocks, it could be justified - but I don't see that happening.

Bundle plugins are meant to support bundles as they are supported in Drupal core. You're looking for a fix in Drupal core, not Entity.

I don't think that's for core, at least not for now. If bundle plugin on config entities would go to core then the whole bundle plugin pattern incl. on content entities should go there, so I'm not sure what's the point here.

It's fine as module maintainers to define the scope of your module as you seem fit - even if I don't see the same. I have come across the need of a number of small fixes and utilities to make it easy implement such use cases and I think that could justify moving this to a separate module. The only concern is why develop and maintain another similar solution It's ok though, after it takes its shape and any benefits are clearer we can consider consolidating solutions here or in core.

I don't know if you plan to ask more maintainers for their take on this, when you think you've made your decision feel free to close this issue.