OK, the fix works for the examples and still preprocesses all files in our
benchmark suite the same way. (I only got differences in four trucks-strips
tasks, but these commonly occur and are likely caused by invariant synthesis
timeouts.)

Marking as resolved.

I'm currently testing a fix that ensures that the translator and hence also the
preprocessor always generate at least one goal (which of course also implies
that there will always be at least one variables). For future usage, I've also
added the constraint that every variable generated by the translator has domain
at least 2.

The new requirements have been documented in translator/sas_tasks.py, along with
our other requirements for "valid" SAS+ tasks. These need to be made more
visible eventually, and we also need to think at some point if and how we can
guarantee these requirements (especially the ones involving sorting) in modified
tasks within the search component. (If we cannot guarantee them there, we cannot
really exploit them anywhere.)

Suggested fix: the translator should always generate a goal. If the problem
"natively" has no goal, then it should emit a trivial solvable problem with one
binary variable, no operators and one goal, similar to the trivially unsolvable
problem of the same form it can already emit. (Of course a problem with a
variable of domain 1 would be sufficient, too, but in other contexts we have
discussed the requirement that all variables should have domain >= 2. While I
don't think we currently enforce it, we might want to enforce it in the future.)

The relevance analysis in the preprocessor will never throw away goal variables,
so ensuring that the the translator emits a goal variable is sufficient for
resolving the issue.

Here is the problem file for the second example.

I suggest we keep the requirement of a non-empty goal and modify the translator
and preprocessor to ensure this requirement is met. In the example problem, the
translator generates a problem with many state variables, but no goal, and in
such a case the preprocessor's relevance analysis will discard all variables.

I'm attaching a second example problem (domain file first) where the translator
already generates a problem with no variables.

And here is the problem file that goes with it.

Here is a domain file that showcases the problem.

As reported on the fast-downward mailing list: in cases where the preprocessor's
relevance analysis detects that all variables are irrelevant, it outputs a task
with no state variables and no goal. The search component does not handle such
tasks gracefully; they are rejected upon reading. We can either fix the search
component to deal with such cases gracefully or the preprocessor to not emit
such cases.