In illustrated form, to go with the previous explanation of this.

The actual configuration change that I just made, amounting to part of one line:

< require_files = $local_part:$home/.forward
> require_files = <; $local_part;$home/.forward;${if !IS_SPAM {!$home/.forward-nonspam}}

(additions and changes have been bolded.)

The amount of added comments necessary to explain this configuration: 17 lines, not counting an entire previous entry (with an antecedent for background). Part of this is to explain the logic and what is going on, and part of this is to explain a necessary workaround because of interactions due to how Exim has chosen to do various sorts of string expansions.

(There are three separate sorts of string interpretation going on in this one line. It's fun.)

Don't ask how long this small change took to develop and test, despite the logic being simple and easily expressed when written down in plain language.

Sidebar: the levels of string interpretation here

Because someone someday may ask, here are the three levels that Exim is doing:

1. a purely textual, configuration file level macro substitution that expands IS_SPAM into an Exim string expansion condition.
2. splitting require_files on the list separator boundaries, either : (original line) or ; (changed line)
3. string expanding the ${if ...} clause.

The separator has to change because (wait for it) IS_SPAM expands to something that has :'s in it. This fooled me during debugging for some time, because the pre-macro-substitution version does not have any :'s so it looks safe from step 2.

A decently designed programming language would be a lot cleaner here. Unfortunately, Exim is probably trying to avoid being a Lisp instead.