(I think I subconsciously had this in mind =)

But it doesn't seem to address the hygiene problem.

As an illustration by extending the synopsis (untested)

sub wrap {
  my ($old_body, $environment) = @_;


  my $new_body = <<'__WRAP__';

    #---PRE_BODY
    my $foo++;      # new var

    #<OLD_BODY>#

    #--- POST_BODY
    print $foo;

__WRAP__

  $new_body =~ s/#<OLD_BODY>#/$old_body/g;


  my $code = eval_closure(
      source      => "sub { $new_body }",
      environment => $environment,
  );

}
[download]

Now the problem starts if $foo is part of the closure environment.

I tried to solve this by using placeholders like $<FOO> in the wrapped code.

This translates (regex) to $_FOO_ iff $_FOO_ is not already part of the environment.

Otherwise it translates to something like $_FOO_A .

(the suffix is incremented till there is no conflict)

Other strategies (gensym, obfuscation, packages) are listed in the WP article, but I wanted to have a notation with readable symbols in the debugger.

I hope it's clearer now.

¹) especially how the use of PadWalker was avoided?

Wouldn't a package give you readable symbols? e.g.

$Some::Package::foo++;      # new var
[download]

instead of

my $foo++;      # new var
[download]

You could also choose a package name in such a way as to reduce the chance of a collision.