I fully understood that bit.

I'm saying that I do not see why that ability would take precedence over being able to validate the value assigned without resorting to callback via tieing (even if it is by the streamlined, inline mechanism). It just seems like an optimisation aimed at the rare case.

I will want to validate every occurance of assignment to an attribute. I (at this stage) cannot see a use for localising it. If it required a callback to achieve localisation for those (I think rare) occasions when I might want to do that but not for the general case , I would see that as a good thing.

But as I said earlier, it is very possible that I am missing the significance of the implementation. I've been sat here trying to understand the P5 code that does this for the last couple of hours and I am none the wiser as to the technical reasoning behind this.

As far as I can tell, with the ability of the code in the sub to decide the target of the assignment at invokation time:

{ 
    my( $x, $y ) = ( 0, 0 ); 
    sub t : lvalue { my $ref = (rand >.5) ? \$x : \$y; $$ref } 
    sub showme{ print "x=$x : y=$y" } 
}

t = 5; showme;
x=0 : y=5

t = 7; showme;
x=0 : y=7

t = 9; showme;
x=9 : y=7
[download]

I don't understand the difficulties? The code has to be run to determine the target (and therefore what would need to be localised).

If, at that point, the code produced a warning or died, or rendered a dummy target that prevented the assignment or whatever other action might be appropriate if the rvalue was deemed invalid because it tested the rvalue supplied to it, I don't understand how that would prevent the correct value being localised if it was valid?