One challenge with backticks ` is that they're commonly used to indicate template or "code" strings. For instance in many markdown variants they require doubling the surrounding backticks to be escaped; I needed to use `` ` `` to get one to render right. They're also often visually difficult to distinguish from single quotes, so may make `mistakes' difficult to spot.

Angle brackets < > would need to be escaped in XML & HTML environments, which are rather common.

Hence parentheses ( ) as something like a least-worst option.

FWIW, in #263 I was trying to say that for literals we might not need separate open/close delimiters, like I'm advocating for in case of patterns. I also have a concern about angle brackets which I shared in #263 (I'm trying to separate the discussion about the design from the discussion about the implementation).

I don't think that round brackets are not much better than "

It means that they become "something to escape", because they can be encountered in plain text.
(I don't know if more often than " or not)

TLDR: same as Addison, "remain uneasy about using such a common character pair."

I don't think that < ... > works either, as it conflicts with many existing "storage formats"

Java can use .xml for resources, and some prefer them to .properties because they are Unicode.
.NET uses .xml files for localization (resx files)
The Apple stringdict file format used for localization is also xml.
Android uses xml for translation.

Even with HTML-like templating. I know of several localization systems for html that "embed" the localizable strings in html:
<p i18n=true>Hello {$user}</p>

It means that they become "something to escape", because they can be encountered in plain text.

There are two "directions" of escaping that we should be considering.

• Inside: what if I want to use the literal's delimiter as part of the literal value?
• Outside: does the literal's delimiter collide with the container's delimiter for strings, or other special characters in the container?

Choosing something else that the single quote, double quote, backtick or angle brackets optimizes for the "outside".

You're right that there may be cases when an "inside" conflict happens. The PR actually makes one of them clear in one of the examples:

{(Thu Jan 01 1970 14:37:00 GMT+0100 \(CET\)): datetime weekday=long}

Do you think a pipe would be a better choice here? Or any other character?

{|Thu Jan 01 1970 14:37:00 GMT+0100 (CET)|: datetime weekday=long}

FWIW, I think I'm OK with {(Thu Jan 01 1970 14:37:00 GMT+0100 \(CET\)): datetime weekday=long} as a trade-off.

Rebased to account for changes in other merged PRs.

@mihnita Did you have concerns about preferring "..." over (...) for literals?

@eemeli needs rebase but ok to merge