>And beyond that, when a naming convention is in use, such as memory variable format of "llFoo" or "lcName" or "lnEstValue" coupled to table field names of "lFoo", "cName" and "nEstValue" (which would've already fixed itself by being different names in nearly every case, but for the cases where there's a logical value called "lNestValue" the ability to use case-sensitive names now removes that issue as well).

analysis of problem correct that only a veryfiable field name difference protects you - my typical example is the lDayIsWorkDay logical field ;-)
For me unless naming convention includes [g,p,l(,t,r)] for variables (t/r if you want to mark parameters as value or reference) AND a leading "d" for datafield to make sure that each field has a prefix of "d" I consider mDot safer bordering on necessary in multi-developer setups. As case-sensitivity might be altered in client installation of a backend server I would hesitate to switch to your approach, although it has its own elegance - and you are used to case sensitive programming from C, but others might be not. In that case a lint-like tool should be added to find programmer spelling errors easier for a language coming from case-insensitive heritage. YMMV.