@Kingwl you might be interested in this one.

It’s not just String.raw, this applies to all tagged template literals, where�?the�?top‑level TemplateStringArray contains�?undefined for�?an�?unknown�?escape, so�?this�?should also�?update TemplateStringsArray:

const taggedTemplate = (template: TemplateStringsArray, ...substitutions: unknown[]) => {
	console.log(template, substitutions);
}

// Logs:
// [
// 	undefined, "bar", undefined,
// 	raw: [ "foo\\uvar", "bar", "baz\\u" ]
// ]
// [ 123, 456 ]
taggedTemplate`foo\uvar${123}bar${456}baz\u`;

Workbench Repro

Also, this doesn’t occur when the�?\u�?follows a�?substitution.

It’s not just String.raw, this applies to all tagged template literals

Sorry I'm not 100% sure what your means.
But seems the runtime behavior is as expected.

The current problem is falsely alarm.

Here's some context:

• add support for Lift Template Literal Restriction�?#23801
• https://tc39.github.io/proposal-template-literal-revision/

And I have found an PR who try to fix a part of the alarm: #41030

The�?definition of�?TemplateStringArray should�?include undefined in�?the�?top‑level index�?signature, which�?should be�?fixed alongside�?this to�?correctly�?describe the�?runtime�?behaviour as�?of�?tc39/ecma262@138c9ef.

Ahhhh Okay. Got the point. Thanks.

I think that dealing with octal escapes in all strings #396 should be done before dealing with tagged templates as an exception...

👋 Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of this repro running against the nightly TypeScript.

Comment by @ExE-Boss

❌ Failed: -

• Hexadecimal digit expected.

Hi, is this issue being worked on? I would like to look into this as a first issue.

Almost created a duplicate to this issue.

The proposal was here, normative section in ECMA-262 here.

@ExE-Boss

The definition of TemplateStringArray should include undefined in the top‑level index signature,

I'm afraid such a change will break existing code. undefined is there only if a part of string template contains invalid escape characters, and this information is available in compile-time. I'd suggest replacing TemplateStringsArray with a readonly tuple of strings and undefineds, intersected with {raw: ...}. of equal-sized tuple of strings. This type should be backwards compatible.