The TC39 minutes are all online [1]. You can see the initial introduction of lookbehind assertions [2], the meeting where they reached stage 3 [3], a status update while waiting for more implementations [4], and then the eventual agreement to move them to stage 4 (full standardization)[5].
They reached that point because: a) everybody agreed that they were a good feature, with precedent in other languages; b) the spec text had been scrutinized by the people who like to spend time scrutinizing spec text; and c) two implementations (Moddable and V8) had successfully implemented them. That's the process, and it was followed to the letter.
Does that put a burden on other engines to keep up? Sure. But that's what we signed up for. The webcompat bug you linked is from April 2020, more than two years after lookbehind assertions were standardized. That's nobody's fault but ours, and we did this project so that we don't end up in a similar situation in the future.
I'm not sure what your source is for JS regexps being impossible to implement from the spec, but if you have specific points of concern, you should open an issue [6]. Writing a spec is hard work, and things get missed, but the people working on this are genuinely trying their best.
(As far as I can tell, Canonicalize is what everybody thought they were implementing. V8 tried to get clever with ICU and ran facefirst into some of the dark corners of Unicode.)
I want to say four things. First, I think Mozilla probably made the right decision here. Mozilla is an org with limited resources and must direct them to what matters - and as you say, regexps are not a plausible battleground. I wish I had said so in my top-level post.
Second, I cast no aspersions against any of the people involved in the ES spec. I recognize they are engaged in hard and unrewarding work driven by a sincere effort to push JavaScript forward, while everyone's a critic, especially myself. It's awesome that the meeting minutes are available. Thank you for the links.
Third, I honestly believe the meeting minutes support my point. I risk overstepping, because I had no involvement, but from your third link:
> We have two implementations. One in V8 and one in the Dart VM. It's not a JS implementation, but it does implement this feature.
This supports my speculation that it's all about v8. Later:
> I would assume Chakra or V8 would have said something by now if they had issues
SpiderMonkey and JSC are chopped liver? This feature really seems to have been driven by the implementors.
And this one feature (lookbehinds) was so disruptive, so damn hard to implement, that Mozilla abandoned their implementation and now just uses v8's. The linked blog post cites this feature as an impetus to switch.
Was that the goal? Did SpiderMonkey engineers give the nod to lookbehinds with the intention of abandoning their engine in favor of irregexp? I have to believe not; I speculate it was the very human response of conflict avoidance. Easier to say "yes" especially if you do not appreciate how much work you are signing up for. But it means ES2018 regexp advanced the monoculture. One less regexp engine in the wild.
Fourth, I really do know that the ES regexp spec is not useful for implementors, because I am an implementor. Ok, it's not really a question, huh; I should just make a PR.
They reached that point because: a) everybody agreed that they were a good feature, with precedent in other languages; b) the spec text had been scrutinized by the people who like to spend time scrutinizing spec text; and c) two implementations (Moddable and V8) had successfully implemented them. That's the process, and it was followed to the letter.
Does that put a burden on other engines to keep up? Sure. But that's what we signed up for. The webcompat bug you linked is from April 2020, more than two years after lookbehind assertions were standardized. That's nobody's fault but ours, and we did this project so that we don't end up in a similar situation in the future.
I'm not sure what your source is for JS regexps being impossible to implement from the spec, but if you have specific points of concern, you should open an issue [6]. Writing a spec is hard work, and things get missed, but the people working on this are genuinely trying their best.
(As far as I can tell, Canonicalize is what everybody thought they were implementing. V8 tried to get clever with ICU and ran facefirst into some of the dark corners of Unicode.)
1: https://github.com/tc39/notes/tree/master/meetings
2: https://github.com/tc39/notes/blob/master/meetings/2016-11/n...
3: https://github.com/tc39/notes/blob/master/meetings/2017-03/m...
4: https://github.com/tc39/notes/blob/master/meetings/2017-05/m...
5: https://github.com/tc39/notes/blob/master/meetings/2018-01/j...
6: https://github.com/tc39/ecma262/issues