Reported issue: spring-projects/spring-framework#35001
This project reproduces an issue with @EnableScheduling annotation added to a seemingly unrelated class (AaaUnrelatedAutoConfiguration),
or collapsing existing conditions in an unrelated class to a single @Conditional
causing existing (and working previously) @AutoConfiguration-s with @Conditional with ConfigurationPhase.REGISTER_BEAN
(e.g. @ConditionalOnBean) being skipped.
AaaUnrelatedAutoConfiguration class has comments for possible changes in the code showing that it's indeed that class that caused problems.
There of course are other options, like in TriggeredAutoConfiguration moving @ConditionalOnBean from the class to the @Bean method
but let's assume we don't want @EnableScheduling being activated unnecessarily.
Similar issues:
But rather than introducing changes to the condition handling for configuration classes, or to the logic of @Import annotation,
maybe it could be possible to add some validation for @EnableScheduling annotation?
Among common "@Enable*" annotations, also @EnableCaching may be worth to protect, other ones are less likely to be used with REGISTER_BEAN phase.
I consider a protection similar to this one: spring-projects/spring-framework#23206
(does not have to be so sophisticated),
or at least some warning in logs (but typically org.springframework.boot.autoconfigure logger is enabled by users, which may not cover that).
Rationale: Those are common annotations, and user does not expect that e.g. collapsing existing conditions to a single @Conditional
in one class can accidentally cause skipping completely unrelated @AutoConfiguration-s.