ES source code is first parsed, then executed. You cannot alter the parser's behaviour with a run-time function.
In that case, not only backtick, but also the ("invalid") embedded expressions will cause problem when exist within comments because they are unconditionally parsed.
Then, I think that the adoption of global (highest priority) comment semantics (eg
//* ...*/, consider
//* as a convenient extension of already existing
/*) might help. These will explicitly de-activate/isolate the content between them while parsing regardless if there are within pure JS, CSS, or HTML code.
What you want has nothing to do with comments, actually.
What I really want is to be able to safely de-activate/isolate, for the purpose of testing, any part (large or small) of the code following the standard ways WITHOUT tricks! I have a (mixed) code consisting of JS, CSS and HTML semantics which JS does not "respect" the CSS and HTML semantics of comment which is the only way to de-activate/isolate code.
At the same time, within CSS and HTML tagged template literals, JS comment semantics
// cannot be used. Also, JS comment semantics
/* ... */ can not be used within HTML tagged template literals.
But that's not exclusive to comments, it's a problem outside comments, too:
html`<div>can I have a backtick ` here? no.</div>`
No, it is not. There is a convention which says
html starts and ends with backticks (`) which is respected. But
<!-- ... --> is official part of HTML which permits the use of backticks (`) inside. Logically, it should be treated as a sealed container, but unfortunately not.
A proven technique for embedding arbitrary text in a different language is with custom start/end tags.
It makes more sense, but does this solve also the problem with embedded expressions which are first parsed?