Okay, let's put this one to rest. I've suspended judgement long enough.
Let me first say that I have my own personal biases, and they are
towards keeping things visually and psychologically distinctive,
rather than towards reducing keystrokes. (Though I have enough
arthritis in my hands to at least empathize with the latter view.)
Leaving aside the use of C<``> as a term for the moment, we will not
use C<`> as an operator in the core. I tend to classify it into the
same visual category as the widely scorned C<�> operator. I have
to think (and squint) for way too long when I see one. It reminds me
(irrationally, I admit) too much of $foo'bar. It's a form of dangling
syntax, and I tend to prefer constructs with a beginning and an end
when I can get 'em.
The flip side is that, since we won't use C<`> as an operator in Perl
6, you're free to use it to introduce any user-defined operators
you like, including a bare C<`>. All is fair if you predeclare.
Most languages won't even give you that...
But I think C<��> is much more visually distinctive, and I don't
mind biasing the language in favor of it for reasons of readability.
It helps people separate the code from the data visually, and that's
a win in the Perl world (if not in the Lisp world). The C<{shift}>
nonsense was a mistake, even if I did persuade people to get used
to it. It is my firm resolve to persuade people to get used to
different mistakes this time. :-)
As for C<qx//>, it probably needs to be completely rethought anyway,
along with C<system>. Perhaps both will be subsumed under a C<run>
function of some sort. But that's for a future Apocalypse.
Larry