The debugger is a bad place to play with scoping like this. In effect when you evaluate single lines like this they're more like doing an eval within the scope of the program (more or less; I'm sure someone more familiar with the perl5db could give more specifics). It's kind of like (handwaving) textually shimming in say DebugDump( eval { YOURTEXTHERE } ) into wherever you're looking at and seeing the result.

$ cat test.pl
use 5.032;
my $foo = 10;
say qq{foo: $foo}
$ perl -d test.pl

Loading DB routines from perl5db.pl version 1.57
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(test.pl:2):      my $foo = 10;
  DB<1> x $foo
0  undef
  DB<2> n
main::(test.pl:3):      say qq{foo: $foo}
  DB<2> x $foo
0  10
  DB<3> my $foo = 20

  DB<4> x $foo
0  10
  DB<5> my $foo = 20; say qq{foo: $foo}
foo: 20

  DB<6> x $foo
0  10
[download]

Simple rule of thumb I tend to follow is just don't use my (or state or our) from the debugger command line to try and affect anything outside of that immediate command line.

You are right. My variables are not always treated correctly, although recently the situation improved. I remember that in the past you just can't work with my variables at all. I just have a utility that stripped my moving them to tail comments and then reversed the situation. But now the usage of my "official" as it is forced by the strict pragma. Which means that such a situation is less acceptable.

Also if you are using recursion my attribute can't be stripped at all. So this is a clear deficiently.

That's sad, because IMHO the debugger is the crown jewel of Perl language environment and remains in certain areas unmatched by competition(macros, flexibility of c command, etc.) Possibility of b lineno ($var eq "value") is indispensable for debugging complex programs. That's what I always stress in my Perl advocacy efforts" "Unmatched by competition."

So any deficiencies here are "highly undesirable."

That's, of course, raises the question of development priorities...

I remember that in the past you just can't work with my variables at all.

Lexcial variables (my) were introduced in Perl 5.000, in 1994 - in fact, Perl 5.000's 26th birthday is in two days.

... my attribute can't be stripped at all. So this is a clear deficiently. ... the debugger ... is indispensable for debugging complex programs.

You seem to be implying that the debugger can't handle lexical variables in the programs one is debugging, which is not correct. The debugger, when used as a REPL, has a few limitations - but it's a debugger, not a REPL. If you're looking for REPLs, see e.g.:

• Perl REPLs
• Re: Custom Arguements
• Best Perl REPL/Shell on Win (and Linux)?

What about my $a=$x=$y=$z = foo()

$ perl -MO=Deparse,-p -e 'my $a=$x=$y=$z = foo()'
(my $a = ($x = ($y = ($z = foo()))));
[download]

The comma is left associative and the assignment is right associative. See perlop.

Here my attribute does not propogate like in case of comma.

No, it doesn't "propagate" with the comma either, as I showed.

That's not what I get nor what I would expect (but this is not in debug mode):

Win8 Strawberry 5.8.9.5 (32)  Sun 10/11/2020 21:47:54
C:\@Work\Perl\monks
>perl -Mwarnings
my $a=$x=$y=$z = 1;

print "|$a|$x|$y|$z|";
^Z
|1|1|1|1|

Win8 Strawberry 5.30.3.1 (64)  Sun 10/11/2020 21:45:55
C:\@Work\Perl\monks
>perl -Mwarnings
use v5.10;

my $a=$x=$y=$z = 1;

say "|$a|$x|$y|$z|";
^Z
|1|1|1|1|
[download]

Update:

What about

my $a=$x=$y=$z = foo()

Win8 Strawberry 5.8.9.5 (32)  Sun 10/11/2020 21:48:09
C:\@Work\Perl\monks
>perl -Mstrict -Mwarnings
use Data::Dump qw(dd);

sub foo { return 9, 8, 7; }

my ($x, $y, $z);

my $a = $x = $y = $z = foo;

dd $a, $x, $y, $z;
^Z
(7, 7, 7, 7)
[download]

It's not the same $a

The lexical scope in the debugger is limited to the eval'ed line. Skip the my to avoid this effect.

edit

Fletch already explained it in detail

Re^3: What's happening in this expression? (Updated)