CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. In most cases this is not correct. A possible capability can be registered from more than one location, and the user then chooses to configure one. And the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, usually the config can only have the same cap in one place.

There are exceptions to this rule though, so allowing more than one registration point needs to be configurable. Exceptions are basically cases where different resources can register the capability, and the authors of those know about this and have coded up the capability implementations to check for duplication and correctly deal it. For example:

1) Both jgroups and and infinispan can provide the same cap, but infinispan knows to check for the presence of jgroups before putting in it's impl. Both are owned by the same author (WildFly clustering team.)
2) On an HC, interfaces and paths can be registered in multiple locations that all end up with the same scope. But they don't have to be. The impl understands the precedence rules between those possible locations and the actual capability reflects the correct config.

I think this latter case is why CapabilityRegistry.registerCapability still allows multiple registration points. But it's a corner case that shouldn't drive all behavior.