After tsc converts the js file, it does not meet expectations

[jsjzgy]

Bug Report

For example, the js code below is saved in the test.js file

(function(s) {
    console.log(s[0]);
    console.log(s.raw[0]);
})`\u{62}`;

After executing the following command, the generated js code is as follows：
tsc test.js --allowJs --outFile test11.js --target es2015

"use strict";
var __makeTemplateObject = (this && this.__makeTemplateObject) || function (cooked, raw) {
    if (Object.defineProperty) { Object.defineProperty(cooked, "raw", { value: raw }); } else { cooked.raw = raw; }
    return cooked;
};
(function (s) {
    console.log(s[0]);
    console.log(s.raw[0]);
})(__makeTemplateObject([void 0], ["\\u{62}"]));

The results of using node to execute two js files are as follows
node test.js

b
\u{62}

node test11.js

undefined
\u{62}

The results of the two files are different, but the result of test.js is in line with expectations.

I need your help, I want to know why the result of tsc conversion is not as expected

🔎 Search Terms

🕗 Version & Regression Information

• This is a crash
• This changed between versions ______ and _______
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
• I was unable to test this on prior versions because _______

⏯ Playground Link

Playground link with relevant code

💻 Code

// We can quickly address your report if:
//  - The code sample is short. Nearly all TypeScript bugs can be demonstrated in 20-30 lines of code!
//  - It doesn't use external libraries. These are often issues with the type definitions rather than TypeScript bugs.
//  - The incorrectness of the behavior is readily apparent from reading the sample.
// Reports are slower to investigate if:
//  - We have to pare too much extraneous code.
//  - We have to clone a large repo and validate that the problem isn't elsewhere.
//  - The sample is confusing or doesn't clearly demonstrate what's wrong.

🙁 Actual behavior

🙂 Expected behavior

[DanielRosenwasser]

Looks like a bug; maybe introduced when trying to fix this: #12700

I haven't looked at the spec, but the behavior is consistent in SpiderMonkey. I think we are incorrectly assuming that \u{62} is an invalid escape sequence.