Regarding this code:

sub fib {
  my $nth = shift;
  (caller)[3] eq 'fib' or $nth !~ m{^\d+$} or @_ and die $fib_die_msg;
  return $nth if $nth <= 1;
  return fib( $nth - 1 ) + fib( $nth - 2 );
}
[download]

That's a perfect example of the sort of things that an expert Perl programmer can understand, but it's not welcoming to newcomers. It also has two serious bugs I see off the top of my head (and that's before parsing precedence, which I can't with that example).

Optional typing in signatures would improve that, for sure - but there's Params::Validate for instance. Then, what should happen if a sub takes an Uint and gets a polymorphic object which resolves to a Uint in numeric context via overloading, but as a filehandle at I/O ? Would we need typecasting? Would the object be aliased to its numeric interpretation in such a subroutine body, or would other slots and/or behaviors still be available and valid?

Again, while Params::Validate is an excellent module, it is not in core and, if it was, it still means it's not core Perl and it's the sort of thing we'd have to remember to use (and to be honest, the confusing interface is an artifact of the fact that it's not core perl).

I'm specifically arguing that core features developers expect in many mature languages should be core to the Perl language itself, and not provided by external modules.

And your comments about "resolves to a UInt" are the sort of issues that many other languages need to resolve. That problem isn't unique to Perl, so Perl should find a way to solve it in a way that fits "the principle of least surprise." I completely agree that we have to make some hard choices (should the string "3" map to the integer 3?), but we shouldn't let these sorts of questions stop us from solving this problem.