I think the "&" should have been accepted as a regular identifier character with the restriction that it could only be used as the first character. That would make "i&mod" and "mod&7" illegal (because in both cases the "&" would be considered as not being the first character.)
Unfortunately, the "&" is a just a scanner artifice, i.e., &anychars = anychars, which leads to strange situations because it is accepted in places other than identifiers (and keywords, which is what it's supposed to "nullify", i.e., "&for" <> keyword.)
I was assuming in my example that it /was/ the first character, and focusing on the potential ambiguity in the numeric constant. That can obviously be resolved by looking at the character immediately after the &, but that's nasty particularly in the context of what's supposed to be a simple syntax.
I'm very uncomfortable with the whole "& escapes reserved words" business. I've seen compilers that were deranged by leading or embedded predefineds hence abominations like reedfyle(), but allowing properly-delimited identifiers to be escaped like that... well, IMO it has no place in a language where the majority of users foam at the mouth whenever they see a C-style "\n" in discussion.
At the same time, this "spaces can be omitted" business rankles because when I've suggested that _ be allowed to indicate array or string concatenation (freeing + for vector operations) I've been told that _'s common use in variable and function names would mean that repurposing it would break too many things.
MarkMLl