What you're suggesting would mean that a Korean user saving a file on their desktop and naming it in Korean would in turn see the filename turn into garbage, which, I hope we can all agree, is not a reasonable suggestion.
Creating 2 different systems carries risks: it has a learning curve, a support cost, and breaks everything that came before.
Perhaps, in a utopian green field, we redo a systems language, a portable systems API, and a common operating system with a compatibility layer to the old way on top.
Not changing impacts many more users (all the future billions) and costs even more: the learning/support/etc. is all there, and it's harder to learn about a buggy system since you have more papercuts
Also, it doesn't break everything, we're not living in a dystopia
2) Change what to what? There are multiple filesystems systems (and OSs) with different and sometimes incompatible filename encodings. Who picks the winner?
3) There is irony on dropping backward compat and requiring UTF-8, an econding whose claim to fame is backward compatibility with ASCII based systems (and not coincidentally was designed by UNIX Elder Ones)
1) so? That will be true for anything
2) sequence of bytes to human encoding. Who picked the loser??? This would similarly be some unidentifiable group of people. You can start by picking the winner for yourself, even at a conceptual level
3) no irony, sequence of bytes is not ASCII
As you say, it can just show the sequence of bytes (plus some visual hints that they are escaped). It is not like nonsensical filenames with seem composed of random numbers are uncommon (e.g. look into your .git dir)
> How else does, for example, your shell find “ls” on your disk when you type those characters?
This is purely a presentation layer issue. The filesystem assumes nothing.