I'd take that wager. 95% of the time, passing more arguments into a subroutine than it expects is a sign of forwards- (and sometimes backwards- ) compatability. Other times, it's a sign of API compatability. For example, I've got a templating module that works with more than one rendering engine. There's a given function that both engines support. But, one takes (and handles) a foo parameter and the other doesn't. If I cannot pass the foo parameter in (to be silently ignored if necessary), that's a sign of bad assumptions.

Be liberal in what you accept and strict in what you emit.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Perhaps the codebases we work with are quite different, but almost every case I've encountered of people passing the "wrong" number of arguments arose because someone changed the signature of some subroutine and neglected to hunt down every use of it.

Of course, one response to that is "don't do that", which is certainly valid to some extent. However, with a sufficiently large codebase, and a sufficiently large number of developers with mixed skills and experience, and a language like Perl where tracking down all uses can be challenging to the best of us, there may be something to be said for paranoia.

If I cannot pass the foo parameter in (to be silently ignored if necessary), that's a sign of bad assumptions.

Your assumption that subroutines silently ignore unknown arguments is the bad assumption. Nothing says this is the rule.

If it's for forwards- or backwards-compatibility then it's not unknown extra arguments. They're there for a reason and the module author is aware of this. Future problems won't arise for you adding those arguments. For my issues with this, see Re^2: Use method/function signatures with Perl.

As for dispatches (like your example with rendering engines), you can take care of this with very little code changes. In your dispatch table (if you have one -- otherwise create one) add which parameters that should be passed (or which shouldn't be passsed, or whichever way suits your problem) and then pass just those parameters. This is trivial to implement for someone like you. For example, a simple draft to illustrate my solution code-wise can look like

sub foo { print "foo: @_\n" }
sub bar { print "bar: @_\n" }

sub safe_dispatch {
    my ($dispatch, $name, $params) = @_;

    my ($code, @keys) = @{$dispatch->{$name}};
    my @params = map { $_ => $params->{$_} }
                 grep { exists $params->{$_} }
                 @keys;
    return $code->(@params);
}

my %dispatch = (
    foo => [ \&foo, qw/ foo common / ],
    bar => [ \&bar, qw/ bar common / ],
);

my %params = (
    foo => 1,
    bar => 1,
    common => 1,
);

safe_dispatch(\%dispatch, $_, \%params)
    for qw/ foo bar /;

__END__
foo: foo 1 common 1
bar: bar 1 common 1
[download]

All I've changed from a trivial dispatch is added parameter names in the dispatch table, and use a subroutine instead of $dispatch{$name}->(%params) which typically would be used.

This approach could easily be tweaked for most other situations and similar problems. I admit there might be cases where this could be cumbersome but for typical use I think it's trivial to get around your problem.

A little code with a great benefit, the way I see it. (See Re^2: Use method/function signatures with Perl for the benefit.)

ihb

See perltoc if you don't know which perldoc to read!
Read argumentation in its context!

For instance passing more args to a subroutine than it needs should IMO not be viewed as a bug. Its behaviour that many a perl programmer would consider completely normal.

We've touched this discussion before (Re: Re: Re: Context aware functions - best practices?). I do not agree. There is no concensus on what will happen with the extra arguments. I'm a firm believer of that documentation is what decides what should be considered a bug or not. If the documentation says a subroutine takes three arguments then I read that as the subroutine should be given three arguments. I don't read it as the subroutine should be given minimum three arguments.

If everyone would live by "it's OK to pass too many arguments" then there would be a lot of unnecessary incompatible updates (i.e. when the module author adds an argument to the subroutine interface). If everyone would live by "it's not OK to pass too many arguments" then module authors wouldn't have to worry about extending the subroutine interfaces and the number of incompatible updates would be reduced.

Assuming that passing too many arguments is silently ignored is to assume things about the implementation, and assuming things about the implementation is by general concensus evil.

Just because it works now doesn't mean it'll work tomorrow--unless documented to do so.

ihb