In 10.2 "Types of Source Code" and 10.2.1 "Strict Mode Code", ...
{1}
The "four types of ECMAScript code" don't cover all source text. There are little exceptions like the BindingIdentifier and top-level terminals of a FunctionDeclaration, but there are also big exceptions like classes.
{2}
10.2 has three long lists of nonterminals, all the same list. 10.2.1 has another list that is almost the same. And there are other repeated bits.
To address the above (and also the points in Bug 4142 and Bug 4145), here's a suggested rewrite of those two sections.
-----------
Source text is divided into regions according to the 'region-defining nonterminals':
Script
Module
ClassDeclaration
ClassExpression
FunctionDeclaration
...
ArrowFunction
Each instance of a region-defining nonterminal in a parse tree defines a region that includes all of the matching source text except for the source text of any nested region.
Source text is classified according to the region it belongs to:
* 'Global code' is source text in a region defined by /Script/.
* 'Module code' is source text in a region defined by /Module/.
* 'Class code' is source text in a region defined by /ClassDeclaration/
or /ClassExpression/.
* 'Function code' is source text in a region defined by any other
region-defining nonterminal.
* ['Eval code' is defined as it is now, just a special case of global code.]
A region is 'strict' if either it is nested within a region that is strict, or it is:
* module code;
* class code;
* global code that is explicitly strict;
* function code whose FunctionBody is explicitly strict; or
* eval code that is explicitly strict or is invoked via a direct eval
that is in a region that is strict.
where "is explicitly strict" means
"begins with a Directive Prologue that contains a Use Strict Directive".
For the purposes of the above definitions *only*, if an invocation of the built-in Function constructor causes source text to be parsed as FunctionBody and FormalParameters, these are deemed to be the FunctionBody and FormalParameters of a FunctionExpression.
[And similarly for GeneratorFunction.]
Re {1}, I now recall that most of a class is function code. However, there's still a non-trivial leftover (ClassHeritage) that isn't any of the 4 "types" of code.
I don't want to do this big a change at this state in the process.
Deferring to Es7 so we can think about a rewrite in that context
okay.