In 15.4 "Array Objects",
under "Runtime Semantics: ArrayCreate Abstract Operation",
step 5 says:
Set the [[NativeBrand]] internal property of A to the value NativeArray.
where "NativeArray" is in a sans-serif font.
I believe this is the only place in the spec where a value of the NativeBrand enumeration is called out with a different font from the surrounding text.
For consistency, change it to a serif font. (Personally, I'd prefer that all the *other* occurrences were called out, but that'd be more work.)
eliminated in rev 12 internal method refactoring.
corrected in rev 12, Nov. 22, 2012 draft
I don't think this has really been resolved.
Allowing for the change from 'NativeFoo' to 'BuiltinFoo', this bug is about the pseudo-code's inconsistency in denoting values of the BuiltinBrand enumeration. i.e. whether or not to call them out via a different font from the surrounding text.
You could fix the bug by making them all not-called-out (which I suggested), or all called-out (which I'd prefer). The former would have involved changing just the one occurrence I noted; the latter would have involved changing every *other* occurrence.
The occurrence of 'BuiltinArray' in the defn of ArrayCreate is still in a distinct font from its surrounding text, and more such occurrences have been called out, suggesting that you were going for the latter ("all called-out") fix. However, many 'BuiltinFoo' values are not called out, so the inconsistency still exists.
(I count about 10 occurrences called out versus about 50 not called-out.)
(Possibly this is a Word vs PDF discrepancy: I'm looking at the PDF.)
we don't use built-in brands at all anymore, but now brand built-ins using double bracketed internal properties so this font issue should now be completely gone.
fixed in rev 16 editor's draft
fixed in rev16 draft. July 15, 2013