is hopefully fairly obvious what's going on - it's not just going to be mixed up with a single quote. Uses like log(f`foo`) should be hopefully discouraged, in the same way that we don't use l (that's the lower-case letter L if you're not reading this email with the numeric codepoints) as a variable, but we are happy enough to write something like limit = 42 - it's clear in the context.

However, I think the Bash example is exactly illustrative of the opposite. So in reviewing at least this one FAQ on  the topic

http://mywiki.wooledge.org/BashFAQ/082, it reminds me of why I don't use backticks in Bash - it's the lack of nesting support when compared to $(...).

Ironically, this nesting is exactly what backticks can help here on - an unused character as of Python 3, commonly used for building some type of string/identifier in a variety of languages, that we can give some nice semantics that allows for simple nesting when used in conjunction with braces delimiting expressions. Such braces of course always give us a new nesting, similar to the statement in the wiki above that "$() forces an entirely new context for quoting, so that everything within the command substitution is protected and can be treated as though it were on its own, with no special concern over quoting and escaping." That this usage of backticks has worked quite well for JavaScript provides some useful confirmation.

I also expect that no one will confuse this with Bash usage, given that's going to be in Python code - except perhaps in a readily written sh function (so something like sh`...`, which returns a list of stdout or something like that and makes use of shlex, etc). I will leave what horrors that could actually look like to the reader :) although in limited form, it could be quite useful.