Currently, everything in the config is read as-is. There is no way to escape characters with special meaning.

This isn't really an issue right now because the config recognizes special characters only if the value starts with ${ and ends with } (references).

However, if we want to allow something like key = foo ${section.key} bar, we need to have a way to escape literal uses of ${ to not irreparably break existing configs.

I would propose the backslash (\) as the escape character because it's the most commonly used escape character.

Having an escape character here would also allow us to implement multiline config options by putting the backslash as the last character in a line (like in bash). This would also make #2207 obsolete.

Unfortunately, just making \ an escape character may break existing configs that use it as a literal character.
I propose a multi-step process to implement this functionality, to give users time to escape their literal backslashes:

1. Add warning or error to config parser for single backslashes

Add an error to the config parser when there is a single backslash in a config value and tell the user to escape their backslashes.
Since the backslash isn't used for escaping anything yet, all single backslashes in a config are literal backslashes.
We should still treat single backslashes as literal backslashes for backwards compatibility.

Because we tell the user to escape their backslashes, we also need to treat two backslashes (\\) as a single literal backslash.
This is the only breaking change here: If a user uses two consecutive literal backslashes, they will now be interpreted as a single literal backslash.
I think the risk of this is quite low.

At this point, the backslash is a proper escape character, it's just not used for anything else than escaping other backslashes.

2. Using the backslash to create multi-line config values

Any config value that ends in a backslash is joined together with the next line (the value will not contain a newline character).
Here, we need to take care to recognize both \n and \r\n as valid line-endings.

For users that have now properly escaped their literal backslashes, this should not break anything.
Otherwise it will break configs where there are an odd number of backslashes at the end of the line.

This would make #2207 obsolete

3+. Introduce constructs with special meanings to config values

We can now start adding things like config values where we can mix references and text.

Each time we do that, it may break certain configs that used that construct in a literal sense (for example someone using ${ as a literal string).

I think we can target 1 for a release and 2 & 3 for the release after that.

The error introduced in 1 should stay and we should also keep interpreting single backslashes that don't escape anything as literal backslashes.

I doubt that many people will be affected by any one of these steps. But I'm sure that there are some people that the backslash as a separator, so we should properly communicate what we're doing.