One of the complicating factors I've encountered in WFCORE-6221, when dynamically registering attributes based on their associated FeatureStream, relates to the current implementation of AbstractAddStepHandler and AbstractWriteAttributeHandler. Both are constructed using a set of AttributeDefinitions, usually prior to registration, e.g. during SimpleResourceDefinition construction, i.e. before we know the FeatureStream of the server.
This means that all implementations of these OperationStepHandlers need to filter the AttributeDefinitions with which it was constructed per operation, since some attributes may not actually be registered.
I don't know the completely history of why these OperationStepHandler base implementations were implemented in this way, however, neither object actually needs to be constructed with any AttributeDefinition instances, since both add operation parameters and resource attributes are known from the ManagementResourceRegistration.
The end result will both reduce the complexity of these OperationStepHandler implementations, and further reduce memory footprint of the server, since not only can we eliminate these data structures per OperationStepHandler, but many of the concrete implementations will now be stateless, allowing multiple resources to share implementations.
Additionally, this ensure symmetric behavior between AbstractAddStepHandler.recordCapabilitiesAndRequirements(...) and AbstractRemoveStepHandler.recordCapabilitiesAndRequirements(...).