Garrett,

I known this.
This is a possible one chosen on one grammatical that describes the language.
When an instruction is complete, the parser ignore the rest of the line.
This is used for simplified the parser machine.

The fact that is used for a comment is only one of the infinite possibilities.
Because all the languages uses a spaces free grammatic,
it can render the code confused,
and introduce (with linguages with runtime macro) indecipherable errors.

But you write:

That's legacy behavior: in early versions of xBase languages, you could have a comment at the end of an IF statement without a comment marker. So, the above is syntactically equivalent to:

IF m.AAA && OR + M.BBB
ENDIF

I agree that it would be just as well to remove this bit of behavior, though.

and this is incorrect.

When VFP implement this, it compile the code ed execute it without errors,
but results are not equivalents, it depends on the situation :

CLEAR
AAA = .F.
BBB = .T.
IF m.AAA  && OR + m.BBB
 ? "a"
ELSE     CCCCCCCC
 ? "B"                 && <==== print this
ENDIF    DDDDDD

IF m.AAA  OR + m.BBB
 ?"a"                 && <==== print this
ELSE     CCCCCCCC
 ? "B"
ENDIF    DDDDDD
RELEASE BBB
IF m.AAA  OR + m.BBB && <==== fire a error when executed
 ?"a"                
ELSE     CCCCCCCC
 ? "B"
ENDIF    DDDDDD

Now i put the proof that this is a parser bug:

AAA = .F.
BBB = .T.
? m.AAA  OR + m.BBB AND NOT + m.AAA   && <=== THIS COMPILE OK AND RUN OK
? m.AAA  + OR m.BBB                   && <=== THIS COMPILE WITH ERRORS

VFP parser have a bug:
for expressions ... logic operator + expression
the compiler ignore the +, but it can fire a error at runtime.

My original case is ( all exists, but runtime fire a error )

... OR exp1 or exp2 or +AliasWA.field=m.variable

Fabio