+1, with a few reservations.
First, In addition to disallowing \r and \n in escaped identifiers, I think characters from this list like U+000B (vertical tab) and U+2028 (line separator) should also be disallowed. I don't think anybody is likely to attempt to use them in practice, but it would be nice to ban all multi-line identifiers consistently.
Second, as @Joe_Groff noted in the pitch phase I think it's important to establish how external tooling/runtime API/etc. is expected to parse identifiers if this proposal is accepted, to avoid inconsistent behavior. I think these should probably require the backticks whenever the compiler would, but it would be nice to have clear guidance ready for tool authors if the proposal is accepted.
I think so. I find the ability to more easily reference operators pretty compelling, especially since it supports the use cases @rxwei described in Operator member syntax - #9 by rxwei. Beyond that, the pitch thread contained enough reasonable, if relatively small, use cases to convince me it has widespread utility.
I see this as a natural extension of the ability to escape keywords as identifiers. In both cases, the backticks are a way of writing a keyword which would not otherwise parse in the given context.
I can't recall ever using a similar feature in another language.
I followed some of the pitch discussion and read the final proposal,