Many undertow subsystem capabilities have inconsistent name resolution

Generally, a capability provided by a given resource is named using as many dynamic segments as it has wildcard resources in its path.
For example, an undertow host is registered at:
/subsystem=undertow/server=*/host=*
This capabilities provided by this resource generally require 2 dynamic name segments, corresponding to the 2 wildcard paths within the address of this resource.

The Undertow subsystem, however, contains several capabilities that do not conform to this rule, with negative implications.

Take the case of an undertow listener. These are registered per server, e.g.
/subsystem=undertow/server=*/http-listener=*

However, the capability provided by each listener is named only by its listener name.
Consequently, multiple servers cannot contain listeners with the same name.
e.g. the following resources cannot co-exist:
/subsystem=undertow/server=foo/http-listener=qux
/subsystem=undertow/server=bar/http-listener=qux

This is not inherently wrong, but immediately becomes problematic when these capabilities are referenced elsewhere. For example, say I want to create a capability requiring an undertow host and listener. This would require 3 attributes, one to specify the listener and 2 to specify the host, e.g.
/subsystem=example:add(server=foo, host=bar, listener=qux)
I can easily add capability references to ensure that such a host and listener exist. However, what I cannot do (without additional runtime validation) is ensure that the specified listener is associated with the same server as the host. If a listener was referenced by both its name and server name, there would be no issue.

UPDATE: Upon further inspection, it seems that listeners are referenceable by name so that they can be registered with a global ListenerRegistry (installed by the remoting subsystem). However, we should still create a second capability name so that listeners can be constrained to a specific server.

Other issues concern resources that provide capabilities with extra name segments.
For example:
/subsystem=undertow/server=*/host=*/setting=access-log
/subsystem=undertow/server=*/host=*/setting=console-access-log
Both resource exposes a capability with 3 name segments, including the server name, host name, and a fixed "access-log" or "console-access-log" value. This 3rd segment is completely unnecessary.

Worse, there is at least one resource that provides a capability with both extra and insufficient name segments:
For example:
/subsystem=undertow/server=*/host=*/setting=http-invoker
This resource exposes a capability with 2 name segments, but this includes the host name and fixed "http-invoker" value. The server name is not a consideration. I suspect this was unintentional?