extremely minor: STOP_SPECULATION sounds better to me

Was there a reason to use this approach over the previous approach? The previous approach guaranteed that saving/resetting state was properly balanced and didn't depend on an external party to remember to reset the state where necessary. Also, this results in object allocations every time we speculate, which could get expensive given how often we do speculation. I'm curious what the performance impact of this approach is over the previous approach.

One approach to avoid excessive allocations would be to reuse the same SpeculationReset object for shallow speculation, or maintain a pool of SpeculationReset objects to use for this purpose.

Another approach would be to have an array to use as a stack for each state variable and push/pop onto the stack, i.e.:

const posStack: number[] = [];
const startPosStack: number[] = [];
// ...
function startSpeculation() {
  posStack.push(pos);
  startPosStack.push(startPos);
  // ...
}
/** @param accept If true, accept the current state; otherwise, reset to the prior state */
function endSpeculation(accept: boolean) {
  const savePos = posStack.pop();
  const saveStartPos = startPosStack.pop();
  // ...
  if (!accept) {
    pos = savePos;
    startPos = saveStartPos;
    // ...
  }
}

I've reverted these changes. You can try that approach in a separate PR if you like.

Does this need to return Fail? It could just return boolean.

No need for the local, inline sigFail.

inSpeculation shouldn't be optional in this overload.

Returning Fail here makes parseDelimitedList and anything that calls it polymorphic, since Fail isn't an array. Consider adding something like a ListFail sentinel value that has the properties of a NodeArray to reduce polymorphism.

I'm concerned about the performance cost of this approach. See my comments in scanner.ts.

Fail may introduce added polymorphism because it doesn't have the same hidden class as a Node. I would recommend the Fail sentinel be a Node instance (possibly using SyntaxKind.Unknown), though you would have to wait to allocate Fail until parse time to ensure the correct objectAllocator instance from services has already been loaded (if present). That would ensure Fail has the same shape and ordering of properties that any other Node instance would start with.

How is {} | null | undefined | void really any different from any in this case? This seems unnecessarily verbose.

Do we need to thread inSpeculation here? The function passed as the parseElement parameter could easily be a wrapper to parse the element with inSpeculation true, similar to parseParameterNoSpeculation below does for the inverse.

Is this wrapper necessary, since the default behavior is the same as parseParameter()?

Removed parseParameter, now should always use this or parseParameterInSpeculation.

I still think that fail and failList should be singleton values local to the Parser namespace. You can easily initialize them for the first time in initializeState so that we don't create excess objects when speculative parsing fails.

return Fail !== undefined && x === Fail; doesn't require the property lookup and verifies that Fail has a value.

return FailList !== undefined && x === FailList; doesn't require the property lookup and verifies that FailList has a value.

For clarity, I would recommend you just return Fail.

For clarity, I would recommend you just return Fail.

For clarity, I would recommend you just return Fail.

For clarity, I would recommend you just return Fail.

For clarity, I would recommend you just return Fail.

For clarity, I would recommend you just return Fail.

Is this still true?

Not important, but I'd be tempted to call this one tryParseParameter and the other one parseParameter. We generally use tryParse to indicate speculation vs. parse to indicate definitive parsing, though that's not always the case.

As above, I'd recommend tryParseArrayBindingElement and parseArrayBindingElement.

As above, I'd recommend tryParseObjectBindingElement and parseObjectBindingElement.