Our projects rely heavily on bean overriding (yes, we know, disabled now by default for good reasons, but still useful at times and a different story).

We now traced down a phenomenon that the name of a @Configuration class found by the @ComponentScan seem to affect, whether overriding with @Import (or sub-classing) works properly. This is though the ConfigurationClassParser already does a lot of handling on this case, e. g. in processConfigurationClass.

Please find a test case in https://github.com/abenneke/sandbox/tree/master/spring-import-order:
It contains four @Configuration classes: Two for a "foo" bean (FooConfigurationA+B) and two for a "bar" bean (BarConfigurationA+B). However, the @Import order is different between both configurations: FooConfigurationB is importing FooConfigurationA while BarConfigurationA is importing BarConfigurationB.

In the test we now see that overriding works as expected for "foo", but fails for "bar"!?

Just to make sure we did not miss anything, we added the very same test using standard Spring methods and again using Spring Boot - but it does not make any difference here.