In "24.1.1.6 SetValueInBuffer", 9.a and 10.a specifies special behavior to avoid writing signalling NaN out to TypedArrays. However, signalling NaN shouldn't really cause any problems for anyone, and this requirement has performance implications. Just remove the word "non-signalling".
(Parenthetically, I'm also wondering, do we need the sentence, "An implementation must always choose the same non-signaling NaN encoding for a distinct Not-a-Number value."? Do existing implementations do this, and does it create a big implementation burden?)
*** This bug has been marked as a duplicate of bug 4381 ***
(In reply to Daniel Ehrenberg from comment #0)
> (Parenthetically, I'm also wondering, do we need the sentence, "An
> implementation must always choose the same non-signaling NaN encoding for a
> distinct Not-a-Number value."? Do existing implementations do this, and does
> it create a big implementation burden?)
That sentence was added as part of bug 3508.
Is that other channel still a concern with the current definition of everything? In https://people.mozilla.org/~jorendorff/es6-draft.html#sec-validateandapplypropertydescriptor ValidateAndApplyPropertyDescriptor, looks like if SameValue, then it just exits early, returning true without writing into the property. So is anything being communicated across the frozen object in that case?
Yes, that issue is still a concern. The summary given in bug 3508 comment 3 describes why using the same NaN encoding for a distinct Not-a-Number value is required.