… but why?

We already have two reasons in core:

1. sub infix:<+> uses the main name as a category of the op and the colonpair as the symbol for the op.
2. In grammars, we have proto regexes. token foo:sym<bar> is one of the variations of foo token and the value of :sym colonpair can be used inside of it for matching that string.

Since colonpairs are allowed in identifiers for the above cases, it naturally extends to $foo also having them allowed.

The Slang-writers can get all the QASTs for colonpairs in <colonpair> token part of the <longname>

Why they must be pairs? Or why do the use colons at all?

Why is this allowed at all. FWIW, there are many things I wish we had written justification for, but I was unsure if this should be included in the docs. Now I learned that there were plans for this, so perhaps more tickets to come :)

Anyway, Zoffix++, this explanation is short and very clear, I like it.

For many aspects of the design, we asked ourselves if there was any generalization that we could achieve without adding cognitive stress to the user. When you already need to be able to name operators uniquely, you can go one of a number of ways: you can force everyone to give things an extra name that fits into the alphanumerics and provide some out-of-band way of mapping them to actual operators, or you can do the Lisp thing and define anything space-delimited as a name, or you can take the custom (read: non-extensible) approach that languages like C++ do. Or, you can come up with a general mechanism to allow quoting or string mapping within special names. We already had the colon pair mechanism available, so it was a no-brainer to use that to extend any name that needs to be able to quote uniquefying but non-standard characters (or other other information with a unique stringification to such characters). The operator names and parsing names mentioned by Zoffix++ are just two special reserved cases of that much huger namespace of names that are extended by one or more pairs. We don't really know how such names will be used in the future, but I guarantee you someone will think of more use cases for names that most naturally identify something uniquely through the use of non-alphanumerics.

To add to the list of established usages of this, module versioning is one, per S11.

Open question: in module versioning the order of the adverbs does not matter. So should
this be the same variable, or is that behavior peculiar to module names?

$ perl6 -e 'my $bar:f<1>:g<2> = 42; say $bar:g<2>:f<1>;'
===SORRY!=== Error while compiling -e
Variable '$bar:g<2>:f<1>' is not declared. Did you mean '$bar:f<1>:g<2>'?
at -e:1
------> my $bar:f<1>:g<2> = 42; say ⏏$bar:g<2>:f<1>;

Should we make a synopsis of what's been said here to the documentation?

@JJ there was an idea on #114 that there should be a faq-why page that would explain some things about the language design. We can start the page with this, yes.