It's a very minor feature request. My proposal is that code like eval("async () => {}"), where the argument is an immediate string literal, should not go through HostEnsureCanCompileStrings.
Literal eval ( "..." ) in source code, where the parameter is an immediate string literal, works mostly the same way as having the code outside eval, just it throws a runtime ReferenceError instead of a static parse-time error and it can run statements in expression contexts. This is useful in certain scripts for safely getting %GeneratorPrototype% and the like in polyfill code, things that are only accessible indirectly via syntax and where the syntax might not necessarily be supported. (Engines could optimize this, but AFAICT they don't.) I've even seen a few polyfills and libraries literally attempt this, though I can't remember specific ones.
However, in the face of CSP and the like, this (very) useful feature-detection idiom doesn't always exist. So could an explicit production CallExpression : `eval` `(` StringLiteral `)` be added to allow for this?
Intentionally, I'm just suggesting adding simple string literals, not template strings or any dynamic string value, and I'm also not suggesting this should be carried to eval ( "a" + "b" ), eval((0, "foo")), or the like, where engines can constant-fold it to an immediate, static string literal. I'm also not including stuff like var foo = "str"; eval(foo). Just the immediately parseable eval("str").
There is the concern of web compatibility, and I'm not sure how often people rely on eval(str) for literal CSP detection. It may be necessary in Annex B to modify it to have a second hook for hosts to hook into (with script data), in case it's mostly web-compatible but not completely, and just recommend they should allow it where possible and practical (as opposed to must). I do understand adding to Annex B is generally not ideal, but it may be the only way this gets through.