der Mouse objects:
> > Likewise, I wouldn't miss characters I can't type at all, and I
> > wouldn't miss spaces very much.
> I would.  I'm unhappy enough over being unable to put a NUL or a slash
> in a component name; I really dislike restricting it even further.
> That said, I suppose it doesn't do any harm as long as I can make it go
> away by removing the appropriate option from my kernel config.  I'd
> even settle for making it go away by adding an option.

I'd agree with that sentiment.  As long as it's configurable (and ignorable)
then I'd have no problem with it, but one big problem with mandating
"no unprintable characters in filenames" is that what's an unprintable
character depends on the character set in question; one person's meaningless
binary trash might be another person's *name*.  (Certainly if you want to
ban characters with the 0x80 bit set, anyway; are there any multi-byte
character sets where 0x0A could be the second byte of a glyph?)

A reason to make this configurable per filesystem:  you may want to export
an NFS volume to users who care about POSIX conformance and/or "unprintable"
glyphs (or even perhaps a data filesystem for a program which generates
binary trash filenames for its own convenience), but still want your local
volumes to be more local-user friendly.  (You'd obviously not run any
carelessly-written tools on the NFS volume, then.)