The Unix filenames provide a mechanism. That doesn't need to be changed. The policy can be different, based on the userbase and the tools being used, but limiting the mechanism to disallow bad policies is wrong.
While you can create a page-long listing of filename troubles, in practice these shell users only end up having to account for filenames with spaces in them. Occasionally you have to rm -- an accidentally created file. Nobody uses those crazy filenames with leading and trailing space, escape codes, and newline characters because it means trouble with the shell. So the problem kind of takes care of itself.
But there might be some future user interface that doesn't have the escaping and expansion problems of current shells and with that it might be useful to be able to put nearly any character into filenames. The Linux/Unix kernel isn't in the position to dictate how the filenames shall be used. It only needs the path separator and NUL terminator and not caring about anything else means less kernel code that can break.
> Nobody uses those crazy filenames with leading and trailing space, escape codes, and newline characters because it means trouble with the shell. So the problem kind of takes care of itself.
I am not talking about idiots. I am talking about malicious users. The issue is a security issue. What happens if you have a windows server attached to a local printer and I upload a file called LPT1.html which contains malicious postscript instructions?
You can't have security without a set of common assumptions regarding allowable input. This occurs on any shared computer system.
While you can create a page-long listing of filename troubles, in practice these shell users only end up having to account for filenames with spaces in them. Occasionally you have to rm -- an accidentally created file. Nobody uses those crazy filenames with leading and trailing space, escape codes, and newline characters because it means trouble with the shell. So the problem kind of takes care of itself.
But there might be some future user interface that doesn't have the escaping and expansion problems of current shells and with that it might be useful to be able to put nearly any character into filenames. The Linux/Unix kernel isn't in the position to dictate how the filenames shall be used. It only needs the path separator and NUL terminator and not caring about anything else means less kernel code that can break.