Another rope-shortener: Fixing filenames

First, which characters are "safe" is going to depend on context. Lots of shell scripts have trouble
with spaces in filenames. Some programs forget to escape strings used inside regular
expressions, so characters like "." and "?" would get in the way. And then there are characters
which can confuse people. Such as "S" vs. "5". Obviously we should only be using one or the
other. This is not even considering all of the variants of the same letter available in Unicode.
Let's also look at filename lengths; the only length that the majority of existing software can
handle properly is eight characters per file, 255 characters per path. Do we really want to limit
ourselves to "protect" against all these things?

Second, this is implementing policy which is in direct opposition to the previous policy: "no slash
or NUL". It would break all kinds of existing applications and scripts, break interoperability with
other systems, and generally make life more difficult.

Third, you can make conventions without enforcing policy. So don't write code which puts
hyphens and newlines in filenames. Just pick an encoding convention and stick with it (UTF-8 is
the obvious choice for Unix-type systems). Basically, take advantage of the fact that no policy is
being enforced by selecting your own.

I'm slightly surprised the proposal wasn't an April Fools joke :(