I don't see how that is problematic.

Semantically, it is problematic because it is not possible the way things are at the moment; and if it is changed, it will break existing code -- which is p5p generally consider sacrosanct.

In my terminology, I'm only returning the value that was in that address -- so the compiler/interpreter can't assign a new value into the variable location.

Implementation wise, lvalue subs always return an lvalue. That's why any attempt to return a constant from an lvalue sub causes an error:

sub x :lvalue { 1 };;
[Can't modify constant item in lvalue subroutine return at (eval 18) l
+ine 1, near "1 }"
[download]

If that was allowed, then x() = 2; would modify that constant.

And even if you only returned an rvalue ("the value that was in that address") when you detected that you were called in an rvalue context -- were that possible -- then it would still break this code:

my $ref = \x(); ## lvalue context, no assignment.

... some time later assign through the ref taken.

$$ref = 'anything at all';
[download]

Currently, and since their inception, that has be both legal and useful.

For a change to be made such that returning an non-lvalue from an lvalue sub was (conditionally) possible; would break any existing code; and the expectation.

FWIW: I wish lvalue subs could inspect the value they are assigned; but I was told very firmly a long time ago that would never be possible; because any assignment happens after the sub returns, in the calling context, long after the sub is finished.