>If we want the safety, the VFPT must add a SET that it obligates to put mDot for get a variable's value.
>
I still don't see a need for a special setting to FORCE the use of Mdot to reference variables. Using Mdot simply removes ambiguity and short circuits the field/variable lookup process to directly access the variable without even considering whether it is a field in the current workarea. VFP might have to first consider whether there is an alias "M" or object "M" but after that litle decision is made, it goes directly to the variable list. Seems like a very logical thing to do.

Without Mdot, there is a "by design" ambiguity that always exists that must be resolved. VFP's "by design" way to resolve this is to look for a field with the referenced name in the current workarea FIRST, then look at all variables that are in scope. If you are referencing the variable but do not use Mdot, you are allowing VFP to work as designed to perform the required lookup to get the value but you are also taking a chance that it may incorrectly access the value from a field instead. Naming conventions can prevent incorrect lookup as long as there
is NO CHANCE of a field to ever have the same name as your named variables.

Field/Variable access errors can be avoided, but without Mdot, the lookup methodology is BY DESIGN to look at fields FIRST. Using Mdot, you bypass this BY DESIGN behavior and at the same time, for anyone who may be reading your code who may have no idea what fields or variables are in scope, whether you think it is UGLY or not, you remove ALL ambiguity as to what you're referencing.

Use Mdot or Not, I don't care. You should always strive to write good code that works exactly as designed that is easily maintained. It can be done either way. My preference is to use Mdot AND use field/variable naming conventions AND remove all ambiguity. If someone thinks my code is ugly, so be it. It works as designed and is as efficient, readable, documented, maintainable and bug free as I can make it. I can live with that.