Yes, I dislike non-named optional arguments to functions ... especially when there's more than one!
Much prefer to handle optional arguments via a single hashref argument because I feel
this scales better over time - to support a new optional argument simply support a new key value
in the hash with a sensible default and old code keeps on working without modification.
This is especially important in functions taking more than three parameters because humans are better at remembering names than orderings -
as indicated by the Perl Best Practices guideline "Use a hash of named arguments for any subroutine that has more than three parameters".
BTW, as indicated at Named Subroutine Parameters: Compile-time errors vs. Run-time warnings, the "reason" given for a hash reference (rather than a hash) was an error in the book:
anonymous hash population is done at run-time, not compile-time;
that said, Conway still stands by this advice because
"Error messages that point users to the right place are definitely worth the (tiny) overhead of passing named args in a hash".
An example of a Perl internal function with a poor interface is split, which has two (update:three) optional arguments
and much surprising magic such as ' ' vs / / vs // vs /^/ as the first argument; empty leading fields preserved,
empty trailing fields stripped by default; negative LIMITs; and many more.
I feel split would have been much clearer and more manageable over time,
if instead of using optional arguments (and special magic values for parameters) it had used a single named hashref argument to specify tricky behaviour.