Hi,

This is a proposal for deprecation, in effort to simplify our bundle/extension ecosystem. It's related to #42647

AFAIK any extension is "config-aware", proven by

And any extension may have a configuration-schema, enabled by: ConfigurationExtensionInterface

To me this is unnessecary layering. The nullability of ConfigurationExtensionInterface::getConfiguration() creates an extra case also.

I propose to deprecate ConfigurationExtensionInterface, in favor of

ExtensionInterface::getConfiguration(ContainerBuilder $container): ?ConfigurationInterface

This conveys the extension config is either schema-based, or mixed.

I dont think config-awareness is needed to initialize a schema. Hence i left out the $config(s) parameter on purpose. Please remind me of a usecase, if it exists :)

If we then reason futher, why not move everything to Extension instead? Thus deprecating ExtensionInterface also.

Or put different, why:

If we then reason further ^^ ..., why do we have ConfigurableExtension actually? Shouldn't the merged config be our final concern? This is probably the hardest to get rid of, in some sane way. But i'd like to solve the $configs vs $config conflict basically.

WDYT?