Regarding the contextual keyword issue, it's not that having both prefix and infix contextual keywords is impossible, but that they introduce complexity that must be managed, and that complexity could easily grow out of control. When new syntax would introduce an ambiguous parse, we must always choose an approach that favors backwards compatibility.

Given the example:

for (using is of and [not/a+"/g]; b++; [/"/g, 5])

We would have to break down the grammar to align with ECMAScript syntax roll-out:

• for..of shipped before using
• using will probably ship before is

Prior to pattern matching, the above parse would treat is as an identifier and and [not/a+"/g]; b++; [/"/g, 5] as an expression. Therefore we would need to maintain that behavior. As waldemar points out, this is a complex issue that will resurface each time a proposal seeks to add a new feature. Unfortunately, I don't think just choosing ~= is a solution to the overarching problem. There are a limited set of punctuators, and combining punctuators in more and more obscure ways will do little to convey their meaning, whereas contextual keywords give us a far wider space for future proposals to leverage. IMO, finding solutions to make it easier to address the prefix/infix complexity, such as automated validators, may be worth pursuing.

var of = [1,2,3];
for(of of of) console.log(of);