[layer8]

Case insensitively is nowadays tied to how (static and dynamic) linking works. You’d either (a) have to use a case-insensitive and thus nonstandard linker, or (b) have to uniformly normalize identifiers before linking, making the normalized identifiers less readable, or (c) have to normalize identifiers based on the casing used for an object’s main definition, which means that changing only the case of that definition still breaks compatibility, so not quite case-insensitive after all, or (d) have at least FFI identifiers be case-sensitive (and use a custom linking runtime for intra-language identifiers).

[noobermin]

>nowadays tied to how (static and dynamic) linking works

and this is the case because of C, which was my point. The fact that OS'es are written in C and thus have a C libraries and APIs is why you must respect C's rules for identifier names.

Also, yes compilers for other languages essentially name-mangle anyway, that's how (modern) fortran which is case sensitive and C++ which isn't (but tacks on a bunch of things to function identifiers) work. But the point about naming conventions or recommendations still stands, like a lot of things it is a fact of history favoring C, not that there is anything inherently better about it.

[layer8]

> and this is the case because of C

I believe it was already the case prior to C with assembly, and really because originally only one case (uppercase) was available. C just didn't change anything about the case-sensitivity of linking.