This is a great question.
Every framework is a product. It can be free to use, it can be open source, but it is still a product and authors want their products to be popular, so most design-wise decisions are made based on the “ease of use” basis. Just like you suggested - framework should be easy to use. So I would argue that they decided to keep it simple and using the same name would cause a lot of problems for developers, let me explain why.
When it comes to frameworks that operate simultaneously in more than one language - like Angular (JS & HTML), we have to pay attention to the specification of both languages. We often come to some sort of cardinality problem. JS is case sensitive, HTML is case insensitive.
appInfo. It might be a bad practice (as it makes the code less readable) but you are allowed to do that. And now, what happens on the HTML side of things?
In Angular names of those two variables will be transformed respectively to
appinfo, two different names, great. So every valid name in JS results in the unique name on the HTML side, awesome.
Let’s take a look at your proposition, in that case, those names would not be transformed and developers would use
Ok, but let’s assume that you don’t create your own language, you just state the rule that developers have to use unique names in a case insensitive sense. As programmes we make errors and then we fix them, that’s our job. I am sure that someone would forget about this rule (as it’s not enforced by the language and tooling) - what happens now? Someone notices that there is a bug in the system and you are assigned to fix it. Trust me, bugs that occur without any error logs or problems reported by the linter are the worst.
That’s why I believe that they went for the easier path, for them as authors of the product and for the developers as the users of the framework.