>>* where you use mdot often depends on context (which isn't always clear [for most people])
>
>???

rephrased slightly: where need you use mdot to avoid ambiguity often depends on context (which isn't always clear [for most people]).
You don't need to indiscriminately use mdot with every variable reference
* it isn't required when it is target of an assignment statement (e.g. foo = value since foo can't be a field )
* when variable is used within macro expansion (e.g. &foo -- due to the language syntax, foo is a variable)
* and a few other cases

what might be confusing (for some) is you shouldn't apply mdot everywhere indiscriminately, as there are cases you shouldn't use it:
* e.g. if you try to use it in macro -- since dot portion would mean to expand variable "M" rather than being part of an mdot prefix
* in the highly unlikely case where you're using WordTech's Quicksilver product (it's rather old, and only for DOS) -- if mdot prefix is used on left-hand-side of assignment statement, it created variable with mdot as part of the name.

>>Although I agree with careful naming convention could be used to avoid variable/field/alias confusion (such application of convention is relatively easy), I don't agree that it makes mdot unnecessary. I (and others) have pointed out it often doesn't work if you have to deal with "foreign" code or tables (i.e. those from a different party). He makes the statement along the lines of "such code nor tables (that don't follow the naming convention) should never be accepted" -- I would counter that by saying that you don't always have a choice on the matter when you're tasked with interfacing with a "foreign" system. You may not always (typically never) have the luxury of imposing your style or conventions on the other system.
>
>Congrats, you're the first one to mention the inherited data structure. I was waiting for that argument to come and I would have expected that people would bring that up earlier. Yes, you are entirely right on the matter here. If you inherit a database over which you have no control and have assessed that there is a significant chance that you will run into a variable/fieldname clash, mdot is most likely the best route (assuming that your variable naming convention is not sufficient).

Actually I'm not the first one -- several people did mention this before.