We tried to improve perf by ensuring that frequently-used fields like kind, pos, end, and flags are all stored in-object:

000003E4E0E47A91: [Map]
 - type: JS_OBJECT_TYPE
 - instance size: 160
 - inobject properties: 17
 - elements kind: HOLEY_ELEMENTS
 - unused property fields: 7
 - enum length: invalid
 - stable_map
 - back pointer: 0x03e4e0e47a49 <Map(HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x034eb1241659 <Cell value= 1>
 - instance descriptors (own) #11: 0x012f0b6cfb21 <DescriptorArray[11]>
 - prototype: 0x012f0b6cf441 <Object map = 000003E4E0E47779>
 - constructor: 0x013a75523b41 <JSFunction Node (sfi = 00000353F65D5C41)>
 - dependent code: 0x020140ac1281 <Other heap object (WEAK_FIXED_ARRAY_TYPE)>
 - construction counter: 6

  [0]: 00000378FA033E49: [String] in OldSpace: #pos (const data field 0:s, p: 7, attrs: [WEC]) @ Any
  [1]: 0000009B539BD2B9: [String] in OldSpace: #end (const data field 1:s, p: 1, attrs: [WEC]) @ Any
  [2]: 0000028DD0EF42B9: [String] in OldSpace: #kind (const data field 2:s, p: 3, attrs: [WEC]) @ Any
  [3]: 0000007EABDD4071: [String] in OldSpace: #id (const data field 3:s, p: 9, attrs: [WEC]) @ Any
  [4]: 0000020140AC45D1: [String] in ReadOnlySpace: #flags (const data field 4:s, p: 8, attrs: [WEC]) @ Any
  [5]: 0000036E885DE309: [String] in OldSpace: #modifierFlagsCache (const data field 5:s, p: 10, attrs: [WEC]) @ Any
  [6]: 000001B37FD2DA09: [String] in OldSpace: #transformFlags (const data field 6:s, p: 0, attrs: [WEC]) @ Any
  [7]: 0000007EABDC4B09: [String] in OldSpace: #parent (const data field 7:h, p: 6, attrs: [WEC]) @ Any
  [8]: 00000378FA0349F1: [String] in OldSpace: #original (const data field 8:h, p: 5, attrs: [WEC]) @ Any
  [9]: 000001B37FD2D511: [String] in OldSpace: #decorators (const data field 9:h, p: 4, attrs: [WEC]) @ Any
  [10]: 000001B37FD24099: [String] in OldSpace: #modifiers (const data field 10:h, p: 2, attrs: [WEC]) @ Any

Just the other day, I had to write an ad-hoc parser for some custom-formatted text file’s lines, as well as some JSON data from a hospital’s record system containing entities within entities…and, before that, the Unicode Character Database’s source text files (though recursion wasn’t necessary for the last one).

Regexes are super common, but I often need more power than regular expressions…and I often need to apply them to non-textual input.

the lambda scope is not mutable

I'm not following, do you have an example?

what if we had another branch for implementers to land pre-stage 3 tests that can help prove out the feature?

test262 has always allowed early landing as long as there's a feature flag

(during stage 2)

my personal take on TDD'ish:

• no test is good before documentation (or specs)
• tests first is useful when you have multiple implementations relying on the same base.
• I support experimenting with implementation regardless of tests but also writing a test when you know the expected outcome but the implementation feels more complex.