Given the experimental nature of :lvalue trumpeted in the Lvalue subroutines section of perlsub, I would be very reluctant to use it with a complex subroutine. If the Perl compiler can't even figure out the simple example code above, what hope for the vipers' nest of conditionals that is the _Var() workhorse?

Point taken -- but to it's credit, _Var was around for a few years BEFORE I added lvalue... i.e. I'd use it:

...(skipping prologue)

my $p=main->SUPER::new({scalar=>1, arr=>[1,2,3,4], 
                        hsh=>{one=>1, two=>2, three=>3}});
#w/o lvalue:

$p->scalar($p->scalar+1);
$p->arr(1,22);
$p->arr(3,$p->arr(3)+$p->arr(1));
$p->hsh("two",22);
$p->hsh("total", $p->hsh("one")+$p->hsh("two"));
P "arr=%s", [$p->arr];
P "hsh=%s", $p->hsh;

    Vs. w/lvalue:
$p=$p->SUPER::new({arr=>[1,2,3,4], hsh=>{one=>1, two=>2, three=>3}});


++$p->value;  #or ($p->value++;)
$p->arr(1)  = 22;
$p->arr(3) += $p->arr(1);
$p->hsh("two") = 22;
$p->hsh("total") = $p->hsh("one")+$p->hsh("two");
P "arr=%s", [$p->arr];
P "hsh=%s", $p->hsh;

#both give same results:

arr=[1, 22, 3, 26]
hsh={one=>1, three=>3, total=>23, two=>22}
arr=[1, 22, 3, 26]
hsh={one=>1, three=>3, total=>23, two=>22}
[download]

For data that doesn't need runtime checking -- just dynamic allocation in a structure, the lvalue'd versions work great and are considerably less visual 'mess' to use, BUT, as you mention, experimental means semi-worthless for production code. As it is, I tend toward using the non-lvalue form in about 2/3rd of new *assignments*. But when you do a read-modify-write, the lvalue form is awfully tempting.

Gonna go poke at the return vals as suggested by Athanasius and see if that clears up the error...