Re: I've got a suggestion...
From a user perspective case doesn't mean anything, and so introducing an artificial and illogical meaning where there shouldn't be one makes Linux less accessible for new users.
This might have made sense when all you were considering was languages based on 7-bit ASCII (i.e. English and some other Latin-derived alphabets*), but in these global days with Unicode catering for a vast variety of languages, many of which aren't "cased" in the Western sense, and where a huge proportion of users may be unfamiliar with Western convention that means two completely different glyphs "mean" the same thing ("A" looks nothing like "a", no matter which font you use) it makes far, far more sense for the operating system to understand every codepoint as a unique value and leave the semantics up to higher level systems.
If you want to make a "user friendly" GUI file manager which is case-insensitive, do so. It shouldn't be any more difficult than the clunky "long filenames" overlays which Windows (and other similar vintage systems) foisted on us.
Just check out what unicode.org says about case mappings.
There was also an interesting discussion around the Python str.lower() function which I found when I was creating a short utility which recognised file types by .extension, and had to cater for ".jpe", ".jpg", ".JPG", ".jpeg", ".JPEG" and several other variants which all mean the same thing semantically about the contents of the file, but which I really, really don't think the operating system should be trying to second-guess. What about filenames which contain spaces+? Should the OS treat 0x20 ("space") the same as 0xa0 ("non breaking space")? Under what circumstances should 0xd7 ("multiply") be treated as equivalent to 0x78 ("x"), and 0xb7 ("middle dot", or "decimal point" to my ancient mind) be treated the same as 0x2e ("full stop")? How about minus-hyphen (0x2d), soft hyphen (0xad), punctuation hyphen, non-breaking hyphen, en-dash and em-dash (various codepoints)?
Can't find that discussion now, but here is the relevant bit from python.org and here's the bit which describes how it's done. It's all a far cry from the days when an uppercase-to-lowercase conversion was as simple as adding 32 to any ASCII code in the range 65 to 90.
Oh, and consider how many of us cut our teeth in BASIC where case sensitivity made life a lot easier - if your variables were all lower-case, you didn't have to worry about clashes with keywords. Was it MS BASIC which only recognised the first three characters of a variable name so a variable named PRICE would class with the keyword PRINT? Even Sinclair worked around that problem, and I grew up with BBC BASIC so it wasn't a problem at all...
Discovering a case-sensitive file system seemed so much more logical!
M.
*ironically, of course, actual Latin as written by Romans some 2,000 years ago wasn't really cased, though I gather that there were several variants of most glyphs, typically to make it easier to handwrite
+an abomination in my eyes, cause more trouble than they are worth. The only benefit of spaces in filenames is to avoid civil war about using camelCase, underscores_or-dashes between words
Biting the hand that feeds IT
