But by and large, most of them are constructors. And where APIs regulary require the user to supply a list of undefs in order to use the call, architypically select undef,undef,undef, 0.1; these are generally and widely acknowledged, even by their authors, as being "ones that got away".

With most functions that sometimes require more than 3 parameters, there is a 'natural ordering' that means that any omitted parameters will come at the end. Eg. substr, splice, read. Even in a function rich API like Perl's there are suprisingly few calls that require more than 3 args, and almost none that require the use of placeholders for distinct functionality.

And that's the clue for me. If an API (beyond constructors), cannot be designed such that any omitted arguments fall at the end, then it is really two (or more) apis that have been conflated. select is the prime example as noted above, and it isn't hard to see how to change that:

• my $old = setStdout( $new );

  sub setStdout {
      my $new = shift;
      return select( $new );
  }
  [download]

• usleep( 0.1 );

  sub usleep {
      my $time = shift;
      return select undef, undef, undef, $time;
  }
  [download]

• select $read, $write, $error, $time );

  Of course, IO::Select does a much better job of dealing with this form.