Ideally the specification approach we decide on is consistent across the family and even the universe. It’s easier IMO to look at this from a user interaction perspective, and to consider which source of info is authoritative. 

For initial consumption there is two ways a user will specify what they initially want:

A) Give me the latest WildFly (latest on a given branch:classifer)

B) Give me exactly this version of WildFly (e.g. WildFly 12.0.0.Final)

As you mentioned earlier in the thread, even when A is used we need to store B so that the prov config is reproducible. Whats also interesting is that in most cases the user does not care what the policy details are for updating to the latest, they will happily accept the default, and really in that scenario the authoritative source is a registry artifact in  the maven repo, not necessarily whats in the provisioning file. The policy details also aren’t important for reproducibility, since the full version already gives you what you need. Where it would be important in the provisioning file is when the user has overridden the rules. As an example, just because a user installs 12.0.0.Beta1, doesn’t mean that from now on they always want betas. They might just want to try a particular beta, and then update back to the main stream. So to resolve the ambiguity, in any case other than the default, the user would have to specify the stream they are interested in.

One other thing to keep in mind, from a usability perspective, is to be careful with using things that look like GAVs but aren’t GAVs

-Jason