The font loader should tolerate backtick strings without template variables about next.js HOT 2 OPEN

This one is not a bug. The error message is clear: Font loader values must be explicitly written literals, suggesting that the code you're using to load fonts expects specific literal values and doesn't accept dynamic or computed values.
When you're using template literals (backticks) like this:

const inter = Inter({
  subsets: [`latin`],
});

The function Inter expects literal values without any computation or interpolation. Even though 'latin' is a string literal, using it within backticks causes the font loader to interpret it differently.

If you're curious and want to know how and why, here's the source code written in Rust: code

Using backticks is preferred when you need to interpolate variables or expressions or when you want to format a string block. Even if you look at JS style guides, JS coding standards, and so on, most of them recommend using single quotes for regular and simple strings.

from next.js.

I understand the error message; the point I'm making here is that a template literal that doesn't contain interpolated expressions has no dependencies on the runtime, and is thus a static string literal.

In other words, what you're saying here is exactly the bug I'm referencing:

using it within backticks causes the font loader to interpret it differently.

Using it within backticks should not cause the font loader to interpret it differently (as long as it doesn't contain any substitution), simply because there's no reasons to do so. Backtick strings are the most refactoring-friendly ones, and while I agree some stylistic guides favour single quotes, it so happens that others favour backticks.

As an example, TypeScript permits backtick strings in places that only permit literals, as long as they don't contain any substitutions. They even have their own AST node: NoSubstitutionTemplateLiteral.

from next.js.