See https://mail.mozilla.org/pipermail/es-discuss/2012-May/022917.html
In the latest ES.next draft(May 4), section 10.5.3 Function Declaration Instantiation step 5 is following
5. For each String argName in parameterNames, in list order do
a. Let alreadyDeclared be the result of calling env’s HasBinding concrete method passing argName as the argument.
b. NOTE Duplicate parameter names can only occur in non-strict code.
c. If alreadyDeclared is false, then
i. Call env’s CreateMutableBinding concrete method passing argName as the argument.
d. If strict is false, then
i. Call env’s InitializeBinding concrete method passing argName, and undefined as the arguments.
In the step d-i, if strict is false, engine always call env.InitializeBinding(argName, undefined).
But if code is non-strict mode, duplicate parameter names may be provided.
And section 10.2.1.1.8, InitializeBinding, step 2 is following
2. Assert: envRec must have an uninitialised binding for N.
So for example,
// this is non-strict function
function test(a, a) {
}
test(1, 1);
engine execute above script and raise assertion failure because of calling InitializeBinding to the same name twice.
The fix for this specific issue is to move 5.d under 5.c:
5. For each String argName in parameterNames, in list order do
a. Let alreadyDeclared be the result of calling env’s HasBinding concrete
method passing argName as the argument.
b. NOTE Duplicate parameter names can only occur in non-strict code.
c. If alreadyDeclared is false, then
i. Call env’s CreateMutableBinding concrete method passing argName as the
argument.
ii. If strict is false, then
1. Call env’s InitializeBinding concrete method passing argName, and
undefined as the arguments.
In other words, on the first occurrence of a name in a non-strict parameter, the binding of the name is initialized to undefined. This allows them to be multiply initialized by step 8.d.
Basically, non-string parameters are treated similarly to var declarations while strict parameters are treated similarly to let declarations.
fixed in editor's draft
fixed in rev10, Sept. 27 2012 draft. But this whole section is going to be rewritten in the near future