If a programmer does the straight-forward thing that comes to mind, namely just using a string, not even bothering to encode to octets, then there is no problem. Both strings and UTF-8 encoded octet sequences work. I personally haven't even run into the problem during the last ten years because it requires special action to set oneself up for failure in order to trigger.

To come back to the topic expressed in the root post, I think nothing needs to be done for Posix. This is a Windows only bugfix.

¹ The big difference to the Windows shitshow where system calls do not work and return error messages, on Posix they do work even if you somehow fuck up the encoding. The file will exist, will be enumerable, will create a filehandle you can operate on, merely the name will display wrong.

² De jure the encoding of a Posix filesystem is unknown and unknowable, but de facto it is UTF-8. I remember dwheeler is doing work to get UTF-8 as default into the next version of the standard, but I can't find the relevant document on the Web.

use 5.026;
use utf8;
use Devel::Peek qw(Dump);

my $string = 'string-año';
#   FLAGS = (POK,IsCOW,pPOK,UTF8)
#   PV = 0x12f4760 "string-a\303\261o"\0 [UTF8 "string-a\x{f1}o"]
my $octets_latin1 = "octets-latin1-a\x{f1}o";
#   FLAGS = (POK,IsCOW,pPOK)
#   PV = 0x12f4420 "octets-latin1-a\361o"\0
my $octets_utf8 = "octets-utf8-a\x{c3}\x{b1}o";
#   FLAGS = (POK,IsCOW,pPOK)
#   PV = 0x12ebb00 "octets-utf8-a\303\261o"\0

my $fh;                         # ↓ displays in shell as: ↓
open $fh, '>', $string;         # string-año
open $fh, '>', $octets_latin1;  # 'octets-latin1-a'$'\361''o'
open $fh, '>', $octets_utf8;    # octets-utf8-año

My point is that two variables that eq sees as containing the same value, create two different files just because of its internal representation.

The representation used by perl internally, should not affect external interactions.

Update: BTW, note that in my sample repl above I have used utf8::upgrade which just changes the representation. Quoting utf8:

Converts in-place the internal representation of the string from an octet sequence in the native encoding (Latin-1 or EBCDIC) to UTF-8.The logical character sequence itself is unchanged.

I have written three attempts at replies with technical details and but I decided to delete them again. I understand all nuances of the problem fully and I am certain you are, too, so writing out the technical details is pointless. We are both looking at a cone and one from the side sees a triangle and one from the bottom sees a circle.

The difference between our perspectives:

• I chose to live in a world where 'use 5.014; use utf8;' is always in effect.
• I never use the functions internal to the utf8 module because its documentation says so.
• It is irrelevant that Perl says $a eq $b is true. In my mind, they are different types. $a is a buf of octets, $b is a string of characters. I have trained myself to notice that it does not even make sense to test for equality without converting one of them first. The only way to convert between the types is the Encode module.
• Representations are an irrelevant concept. If I have a string, I know it's UTF-8, and system calls on Posix will happily do the right thing.
• By applying the discipline of the best practices rigorously I will not possibly get myself into a situation where the problem you showed can occur.