see https://mail.mozilla.org/pipermail/es5-discuss/2011-January/003904.html
I don't think this is directly address by the specification but I think we have sufficient clues in the spec. to tell us how they should be handled.
10.1 and 10.1.1 defined "Function code" and "strict function code" as source text that is part of a FunctionBody. that would seem to exclude the function name and formal parameters. However, 13.1 explicitly applies strict mode restrictions concerning the use of "eval" and "arguments" to a "strict mode FunctionDeclaration or FunctionExpression". Unfortunately, the spec. doesn't appear to explicitly define "strict mode FunctionDeclaration" or "strict mode FunctionExpression". It does define "strict function code" but in a manner that only refers to the FunctionBody. However, the semantics of FunctionDeclaration and FunctionExpression in 13 treat the construction of a function as a strict function if its FunctionBody is strict code (meaning it contains a Use Strict Directive). In addition, 13.1 explicitly mentioned that strict mode restrictions on the use of "eval" and "arguments" or with duplicate parameter names apply to the formal parameters of FunctionDeclarations and
FunctionDeclarations.
From this, I think we can reasonably conclude that the intent was that strict mode restriction apply to an entire FunctionDeclaration or FunctionExpression and not just the FunctionBody. The function name Identifier is syntactically part of a FunctionDeclaration or FunctionExpression so it would be consistent for any restrictions to also apply to it.
Also, note that the "backwards" impart of the already explicit formal parameter restrictions for strict mode functions is similar to what is required to also apply the FutureReservedWord restriction to either the function name or the formal parameters.
In addition, in the case of FunctionExpressions the only place the function name has a visible binding is within the FunctionBody. The only semantically significant reason to give a FunctionExpression a name is so it could be referenced from within its body but if its name was a FutureReservedWord and the FunctionBody contained a Use Strict Directive any reference to that name from the body would be illegal.
Finally, I can testify that if I had thought of it or if somebody had mentioned it I would have listed the FutureReservedWord restriction on function names and formal parameters in 13.1.
So, sorry, but I don't think I can simplify your life in this case. In the next errata FutureReservedWord errors for the function name and formal parameters should be added to 13.1.
Allen
from July 2011 meeting notes:
Deferred but this was considered straightforward, per the comment 0.
this is fixed by consistent use for BindingIdentifier in these contexts