Early Capping of Caret?

[j-mie6]

When parsing strings, the entire width of the string attempted to be matched is pushed into the caret. But this can lead to odd results like this one:

(line 1, column 3):
  unexpected "ud8"
  expected "&", end of escape sequence, or string gap
  invalid escape sequence
  >"\ud800"
     ^^^

Here, the error really should read unexpected "u", but because escape sequences contain 3 letter strings, it is stretched. One way to change the semantics would be to only demand a character as wide as the string actually could match + 1, instead of the whole string.

Another approach, suggested by Aly on the discord, would be to cap the caret at the minimum of the viable alternative demands (sans 0). This scheme also seems reasonable and would fix the above issue (incidentally, mind). The min/max behaviour could even be controlled at the ErrorBuilder level, perhaps?

Regardless, it's arguable this above problem occurs because the labelling of the escape sequence hides information about the length of the underlying options... Is there a way to fix in this case?