[jodrellblank]

https://prnt.sc/257kxxa lowercase l and uppercase I are quite distinct. If you're going to select all your filenames with autocomplete, then why argue restrict me to case sensitive filenames?

Windows NTFS is sometimes described as case-preserving, case-insensitive; i.e. if you name a file "Test" it will stay in that case, but if you ask for "test" it will find the file "Test". I don't know whether that happens in Win32 or NTFS, but it seems like best of both worlds; I don't want "case insensitive" where it could show me the name in a different case than I entered.

[hvdijk]

For the record, this is how lowercase l and uppercase I show up here: https://prnt.sc/258zzy0

[jodrellblank]

And this is how they show up here: https://prnt.sc/259t3qy

I don't override the font, either HN or FireFox or Windows is picking a serif font. I assume you didn't explicitly choose a font where different things look the same, but if it rendered 'a' and 'Z' the same glyph, you wouldn't say that was a problem with the English alphabet or with case sensitivity, or anything other than bad font design, right?

[hvdijk]

You showed a screenshot earlier, I know what they look like for you. :) I don't override the font either. HN specifies a CSS font family "Verdana, Geneva, sans-serif", where Verdana is installed by default on Windows but is not a full sans-serif font, so it's a somewhat odd choice by HN. As for the English alphabet, I didn't say there was a problem with it, just that you cannot reliably tell just from looking at letters which letters they are. In practice it is not an issue.

[jodrellblank]

Frankly, the use case where I make a file to send to a customer "Example Ltd DNS details" and want to open it from a command line happens to me infinitely more often than the use case where I have a file called "fiIe.txt" and want to open it from a command line.