Most BeanDefinitionParsers are candidates for extraction of a FeatureSpecification type usable from within @Feature methods.
Some are not. For example, PropertyPlaceholderBeanDefinitionParser (context:property-placeholder) need not have a dedicated FeatureSpecification because (a) the implementation of PPBDP is so simple, and (b) a Property(Sources)PlaceholderConfigurer can be configured and returned directly from a @Bean method - no @Feature required.
At time of this writing, there are certain BDP impls for which it's not certain whether a FeatureSpecification extraction is appropriate. Titles for these subtask issues below are prefixed with "Investigate ...". These BDPs need to be evaluated as to whether they genuinely represent a "feature of the container", or are simply a convenience for registering a single bean. In the former case, a FeatureSpecification should likely be extracted. In the latter, direct translation to @Bean methods by users should be straightforward.
In cases where no dedicated FeatureSpecification is introduced, the BeanDefinitionParser implementation and probably also the XSD documentation should be updated to reflect how the functionality provided by this parser/element should be achieved when using @Bean methods to configure the container.
You'll notice that a subtask exists below for nearly every Spring XML namespace element shipped with the core container. Even though some elements/parsers are not candidates for FeatureSpecification extraction, the subtask remains in order to provide a single point of reference for users and maintainers about these decisions. Issues such as
SPR-8166 (regarding jdbc:embedded-database) are resolved as "Won't Fix" with an explanation why a FeatureSpecification refactoring is not necessary and instructing users how to achieve the same functionality in a @Bean method (configuring an EmbeddedDatabaseBuilder and returning its DataSource product).