Okay, that now makes sense.

What actually helped shed light on it was using your ctx function in this code:

sub ctx {
  my $w = wantarray;
  print "$_[0]:";
  print ( defined $w ? ($w?'array':'scalar') : 'void');
  print "\n";
  \&ctx;
}
sub ctxind {
  my $w = wantarray;
  print "$_[0]:";
  print ( defined $w ? ($w?'array':'scalar') : 'void');
  print "\n";
  1;
}

my $a = [ ctx("buildA1"),ctx("buildA2"),ctx("buildA3"),ctx("buildA4") 
+];
ctx("by itself");
@{$a}[ctxind("slice ndx")];
$a -> [ctxind("plain ndx")] -> 
    ("fn1",ctx("args1"),ctx("args2")) -> ("fn2",ctx("args3"));
[download]

buildA1:array
buildA2:array
buildA3:array
buildA4:array
by itself:void
slice ndx:array
args3:array
args1:array
args2:array
plain ndx:scalar
fn1:scalar
fn2:void
[download]

Which now all makes sense, except for the "args3" being evaluated before "args1". That seems like a rather bizarre evaluation order.

The contexts inside () on the function references are all array context, and the context inside [] is array or scalar depending only on the immediately surrounding syntax. The context of the function called by the dereference itself depends on the surrounding code.

I guess if TIEARRAY worked better, I'd be able to tie the array that $a points to and see that the FETCH method was getting called with different contexts depending on the code surrounding the array ref, even though the context applied to the expression generating the index was determined only by wheter I'd used the slice syntax or not. Unfortunately, it appears that FETCH is always called in scalar context, no matter what.

@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
[download]