The current spec draft shows optional function arguments as "[optional = undefined]". This combines the notation used in the ES language specifications, "[optional]", with the new notation for use in ES6 programs, "optional = undefined", and is redundant. The value undefined for optional arguments in built-in functions is specified by ES6 section 17.
I suggest reverting to the notation used in the ES language specifications, "[optional]".
Sorry, part of what I wrote in the description was wishful thinking: ES6 section 17 specifies undefined as the value if *required* arguments are not provided; it doesn't say anything about optional arguments.
However, I don't see the language spec saying what the spec notation "[optional = undefined]" means, and I also don't see it used anywhere. So I think it's better to revert to the old way of filling in argument values as part of the algorithms.
It replaced any algorithm text that had previously explicitly set those to `undefined` if the value argument wasn't present. I'm going to remove them because they are indeed unnecessary.
Fixed in rev7
No, I don't think (anymore) that this works. There needs to be something in the specs that says what happens when the caller doesn't provide an optional argument. Contrary to what I claimed in the description of this bug, ES6 section 17 doesn't specify that. So we need the steps that the algorithms had in ECMA-402 first edition.
That's what I was using the default parameter for; in those "not provided" cases, the value was set to `undefined`, then the algorithm would proceed. I will go back and double check the 1st edition to confirm that.
"not provided" is used extensibly in 262, I think we can now close this.