+When it happens that the same module is available from more than one
+authority, and the desired authority is not specified by the C<use>,
+the version lineage that was created first wins, unless overridden by
+local policy or by official abandonment by the original authority (as
+determined either by the author or by community consensus in case the
+author is no longer available or widely regarded as uncooperative).
+An officially abandoned lineage will be selected only if it is the
+only available lineage of locally installed modules.
+Once the authority is selected, then and only then is any version
+selection done; the version specification is ignored until the
+authority is selected. This implies that all official modules record
+permanently when they were first installed in the official library,
+and this creation date is considered immutable.
For wildcards any valid smartmatch selector works:
use Dog:ver(v1.2.1 | v1.3.4):auth(/:i jrandom/);
So now you've explicitly stated what I implicitly (or maybe explicitly) thought
before, in that version numbers are always subordinate to authorities, and only
make sense in the context of an authority, though an explicit authority doesn't
have to be declared in user code.
I propose that the canonical order of entity long names be altered so that the
:auth always comes first, and :ver second, when both are used.
use Dog:auth(/:i jrandom/):ver(v1.2.1 | v1.3.4);
The documentation should be in that order, not the other order. Then I think
the syntax better corresponds to the actual interpretation, conceptually where
each new trait (or trait-looking thing) is interpreted in the context of those
before it. And I don't just mean example code, but explanation order too.
-- Darren Duncan