Why should I assume that my console is using UTF-8?

Sure, that's a valid point. But then again, if someone is going to be writing Unicode data to the console in the first place, what encoding should they use? If this is a tool in a UNIX command pipeline, UTF-8 seems fine to me, it can be piped to iconv, or one can add a command-line option to change the output encoding if desired. What the best way is depends on the situation; my point was just a response to your apparent complaint about the warning from Perl.

But most importantly, if you automatically open all files in UTF-8, then you'll have serious limitations.

You can override the default by explicitly specifying an encoding in open.

What if you do want to check for UTF-8 encoding errors?

use warnings FATAL => 'utf8'; - people also add this to their boilerplate for that reason. (Update: I've added it to my boilerplate above.)

What if your file mixes binary and UTF-8?

In that case you'd have to fiddle with binmode or a manual decode anyway, no matter what the default encoding is.

File::Spec is a disaster.

It does have its faults, but in general, I disagree - in my experience it's much more common for people to put bugs in their code* via their reinvented wheel filename handling. But anyway, its canonpath removes a trailing slash. Of course, if you're certain your script will only run on POSIX systems, you can just use a regex to strip the trailing slash.

* Update 2: Or at least make their code less portable. Also, note the module's canonpath does collapse "/a///b/" to "/a/b".