Part of the axiom meta-issue issue924.

Thanks for bringing this to my attention, Erez! The comments in msg898 still
apply, so I renamed the issue to better reflect what needs to be done and
removed the 1.0 keyword.

I think this is also resolved (but I'll let Malte close this one).

One thing we should *really* look into is how derived predicates are treated by
our heuristics that support them.

In particular, I think at least one of our implementations at one point simply
treated axioms are zero-cost operators. That means that if an axiom is currently
true [*] and has to be false [*] in the goal or for some precondition, we'll get
h = infinity since there's no explicit rule that sets axioms to false (they are
only false "by default" if none of the rules triggers, never set to false by an
explicit rule*).

This is essentially the reason why we have "extended domain transition graphs"
(see JAIR paper on Fast Downward) although I'm not sure if and where they're
currently computed and used.

[*] "true" and "false" in the sense of "proved by a derivation rule" and "no
rule applied" -- in the code, "true" might actually correspond to "0" and
"false" to "1". Not sure.

The "conditional effects in FF heuristic" issue is now separate: issue166

Some of our heuristics (e.g. h^FF) purport to support conditional effects and
derived predicates, but the support is somewhat strange. For example, if I
recall correctly, our h^FF does not actually generate proper relaxed plans on
tasks with conditional effects because each action is only counted once (but
might be required multiple times). Similarly, support for derived predicates,
where they are accepted at all, is shaky.

In the long term, this should be fixed. For version 1.0, this should at least be
documented properly -- including a warning at runtime, maybe even a required
option that says "I'm aware of these limitations, let me use these heuristics on
these problems regardless".