It sounds like most of these problems are "CLIs suck, since it's hard to parse commands and filenames". GUIs don't have these problems. And Apple solved the pathname problem in the Classic MacOS by not having paths - references to files were to be stored as "alias" data structures, which contained the inode ID (so despite moving files around, a reference would still point to the original file).
For example, all GUIs must display filenames (say in a file-picker), but how do you display the filenames if you don't know what the encoding is, or if the filename disobeys the encoding? What should you show a user when "control-A" is one of the "characters"? How can you give line-at-a-time display when newline is in a filename? How do you process filename, since it may not be a legal string in the current encoding (a problem both Qt and Python have hit)?
The Qt solution is to mandate that filenames must be in UTF-8. Period. So the nonsense that "filenames can be almost any sequence of bytes" is just that, nonsense. It's silly anyway; why allow ALMOST anything, but not anything?
This also assumes that GUI programs never invoke other programs, which is also absurd. Every time a GUI does system(), exec(), and so on, it risks these filename problems (e.g., if it tries to pass a filename with a leading "-").
The problems are WORSE in shell, but they still occur in other languages.
The difference is that in a GUI, even if you fall back to displaying a foreign or poorly-encoded filename as a bunch of Unicode entity squares, the user can still preview, open, edit, move, rename or delete the file. On the command line, you can't do anything with it if you can't type the name.
