1. any assignment to a new variable leads to an implicit my but only if their was no previous explicit declaration in a surrounding scope. This will replace former rules 1,4 and 5 all others still apply

Hence we get the following 4 cases for explicit declarations with my or our

automine	effect	comment
{ $x = 1; { $x = 2; } } [download]	{ my $x = 1; { my $x = 2; } } [download]	not strict w/o automine
{ $x = 1; { my $x = 2; } } [download]	{ my $x = 1; { my $x = 2; } } [download]	not strict w/o automine
{ my $x = 1; { $x = 2; } } [download]	{ my $x = 1; { $x = 2; } } [download]	backwards compatible
{ my $x = 1; { my $x = 2; } } [download]	{ my $x = 1; { my $x = 2; } } [download]	backwards compatible

Surprises and pitfalls:

automine	effect	comment
sub foo { if (1) { $x = 2; } print $x; } [download]	sub foo { if (1) { my $x = 2; } print $x; # undeclared } [download]	Doesn't compile Surprising for Pythonistas
sub add { $x = 0; for (1..9) { $x = $x + $_; } print $x; } [download]	sub add { my $x = 0; for (1..9) { my $x = $x + $_; } print $x; # prints 0 } [download]	Unexpected result! Needs an explicit my $x = 0 at init to avoid implicit my

This is a very Perlish approach and avoids many edge cases.

Of course this laziness comes with a price, introducing a new explicit declaration on file scope has an effect at the distance and could silently break subroutines

use automine
# our $var;

... 

sub foo {
    $var = shift; # not 'my $var' if explicit 'our $var' exists 
    ...
}
[download]

That's why this theoretical pragma must be optional. (Of course scoping the our inside a tight block would also prevent this.)