Besides using the field's notation (why we still can't werite greek letters easily?), I also like it a lot to use case to differentiate between kinds of elements.

For example, let's say you want to write code that communicates with an arduino. You can define a class named "Arduino", that'll be instantiated on other classes, and the instances can be called "arduino", with no problems at all. On case insentive languages one has to resort to worse names, like "arduino_t", or "arduino_instance".

What if it was only for things in the same "class" (wrong word, but I'm not sure what to actually call it)?

So variables only with variables, classes only with classes, functions only with functions?

(I.e. you can define a class called Arduino (bad name, by the way) and a variable named arduino, and it won't complain, but if you then try to define a class called "ARDUINO" or a variable named "ARDUINO" it will error out.)

That would make a class of error impossible, at the cost of losing consistency (in most modern languages, the class name is just a variable that holds a class value).

I'm not decided if I like it or not.

I like there to be a difference between a variable “p” and a variable “P” (the former, for example, might be a vector, whereas the latter could conceivably be a projector onto this vector). Especially when doing numerical work, I found it to be extremely helpful to stick to established notation in the field also in the code intended to implement the algorithms written in this notation. In this sense, I find it sometimes sad that C++ doesn’t allow boldface/curly variable names :)