You're right. I did not explain that well enough. Even with sigils it is unclear whether qv_mult will take 1 or 2 arguments, or whether qq_mult will take 1, 2 or 3. What is however clear is that only qq_mult and qv_mult are function calls, which it previously was not. Worse, what i did not mention then: When reading carefully it was easy to tell that they had to be function calls; however it was impossible to tell whether the two quaternions and the vector were variables, or function calls that did not take any arguments. Only with sigils becomes this clear.

I'm still unclear on what the dataflow is... is w set to the value of the qq_mult call and the rest just executed for side effects?

Regardless, please defend how that is not just an improvement over, but better than, say:

    my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector;

    w = qq_mult(qv_mult(CondugateQ, Vector))
         

or whatever the precedence and dataflow semantics are

That example doesn't show it very well. To be clear: The intended advantage is: Parens are optional. That permits syntax like the following to be implemented in pure Perl without changing the parser:

    try {
        die "foo";
    }
    catch {
        warn "caught error: $_";
    };

If parens were mandatory, it would need look like this:

    try(
        sub {
            die "foo";
        }
        catch(
            sub {
                warn "caught error: $_";
            }
        )
    );

Having the nicer form in the first example is possible only because sigils are mandatory, along with auto-flattening variables and easy code highlighting.

As for the example, with mandatory parens it would look like this:

    w = qq_mult( ConjugateQ, qv_mult( RotationQ, Vector ) );

In production i'd write it like this:

    my $W = qq_mult $ConjugateQ, qv_mult( $RotationQ, $Vector );

That gives a nice balance between a low number of parens, and clarity of intent.