WildFly reacts to the following jboss.api values in module.xml:

private
unsupported
deprecated

Anything else is considered 'public', so it's ok for a deployment to declare a dependency on the module.

This somewhat breaks down though because there are other use cases for user use of our modules beyond use by deployments:

1) Modules might package types that serve as an API for user-provided classes that are declared via classname+module attribute pairs in management API resources.

2) Modules might be supported as dependencies of user modules that provide org.jboss.as.controller.Extension implementations. (Note: WildFly supports such use; JBoss EAP does not.)

Allowing such use doesn't mean it's ok to support use in deployments. But we have no way to declare this. In some cases we've marked modules as private and then added lengthy module.xml comments to explain the permitted use (search for 'END USER MODULE USAGE'). But I don't believe we do this for public modules. And such comments don't really help formalize the different 'legal' usage patterns and make it relatively simple to search for modules that are valid for them.

Perhaps adding more values to jboss.api isn't the answer; perhaps some other property/properties are better, and then once we have those we change jboss.api to private for any modules that are 'public' for reasons other than availability for use by deployments.

Note that 'jboss.api' means nothing in the software outside of org.jboss.as.server.moduleservice.ModuleLoadService, which checks for the 3 values noted at the beginning and logs a WARN if the deployment has added a dep on any of them. So, so long as we continue to check for jboss.api and react, and thus continue to handle any existing modules maintained elsewhere, we are free to add new properties, replace the existing property, etc.