Perhaps we're misunderstanding (some portion of) what Walter has been saying -- probably due to how he's been wording his responses, along with some conclusions he's arriving at: What I think he might be saying is the following:
* mdot isn't necessarily bad, but using it as your only defense is bad if you're not using it in *all* cases (where it would avoid potential problems)
* where you use mdot often depends on context (which isn't always clear [for most people])
* there are some known cases where mdot won't work -- such as in the case where alias names or fields that clash with identifiers such as THIS and THISFORM, or where alias or fields that are named "M" (IMHO these are "pathological" cases demonstrating problem with poor identifier choice rather than a failing of mdot)
* if you're not applying mdot where required (to avoid problem), it's not any different than not using it at all (don't completely agree as I see this as a broad generalization)
* Applying a careful naming convention (consistently) obviates the need for mdot (to avoid variable/field/alias confusion).

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.