Textmate engine bug for `\k<>` backreferences

Example of working as expected

Input is on the left, output is on the right.
The "end" pattern is referencing the 2nd group created in "begin" (the EOF)

What (intentional) failure looks like (non-issue)

A bad pattern causes this kind of behavior:
(note: yellow is the theme's color for entity.shell, which is the included pattern)

What is broken

\k<2> should be equivlent to \2 and in other places it does behave equivlently

However, instead of failing normally (e.g. all-yellow) it seems to trigger undefined behavior:
(Note: \2 is not a viable workaround when group numbers are ≥10)

Here's the code for the problematic pattern.
This is for VS Code 1.72.2, on Mac M1

{
    "begin": "(<<)\\s*+\\s*+((?<!\\w)[a-zA-Z_][a-zA-Z_0-9]*(?!\\w))(?=\\s|;|&|<|\"|')",
    "end": "\\2",
    "beginCaptures": {
        "1": {
            "name": "keyword.operator.heredoc.shell"
        },
        "2": {
            "name": "string.delimiter.shell"
        }
    },
    "endCaptures": {},
    "name": "string.unquoted.heredoc.no-indent.shell",
    "patterns": [
        {
            "match": ".+",
            "name": "entity.shell"
        }
    ]
}

Start by reproducing the supplied begin/end grammar, comparing the \k<2> and \2 backreferences in the TextMate engine. Trace how begin and end backreferences are parsed and handled, including group numbers of 10 or more. Done means invalid backreferences fail normally instead of causing the reported undefined behavior.