The second reason to reject warnings usually is "that belongs in a lint utility like Perl::Critic.

A third possible reason can be that some stuff is surprisingly hard to implement in perl5 because it doesn't keep a parse tree of the whole program, but discards the current part of the parse tree as soon as it can be turned into an op tree. Which makes static analysis non-trivial, in some cases (I don't know how it is in this case, though).

Currently I think that a warning is not a bad idea.

I agree... it's hard to agree on what the behavior is (probably why it has remained undefined) but if the behavior is "undefined" then a warning should be emitted either under "use warnings" or (my preference) "use strict".

Could you not add a new category for this under "strict" or "warnings" so that you could say:

use strict;
no strict 'postfix';
[download]

That might satisfy the gurus who have code that depends on this "weird" behavior.

Having to add another line to your code isn't their notion of backwards compatibility, and in this case I have to agree.

And not making it a default would also be weird, because in the case of strict it would require two lines (use strict; use strict 'postfix';), and in the case of warnings it would imply that use warnings; isn't the same as use warnings 'all';, on which others rely.