@Controller is excluded since it's not likely to have multiple implementations in practice.
Comment From: quaff
Should I submit https://github.com/spring-projects/spring-framework/pull/32302/commits/7628ae05f566018847c7a0580dad8b5b9fbe1e17 in another PR?
Comment From: jhoeller
I'm afraid that we do not intend to take these flags to the component stereotypes. Stereotypes are high-level annotations with just a name suggestion and no other semantic relationship to bean definitions or the core container, or the notion of qualifiers. Exposing specific settings there would amount to a semantic leak from beans.factory.config to the stereotype package.
The defaultCandidate flag is even more nuanced in that it only applies with specific AutowireCandidateResolver implementations that understand the semantic distinction between a qualified match and a plain match. For that reason, it is not exposed on the BeanDefinition interface, in contrast to the generally applicable autowireCandidate flag.
For a configuration arrangement that relies on qualified matches, I would strongly recommend a configuration class arrangement with @Bean methods in any case. Configuration classes provide a bounded unit with easily discoverable bean definitions and qualifier alignment, even when the individual factory methods just delegate to a component constructor.
Alternatively, a BeanFactoryPostProcessor could be used to change those candidate flags for a whole range of bean definitions, including component-scanned ones that got detected via a stereotype.