We expect this to be resolved when issue247 is resolved.

Keeping both active is fine if you think it makes sense. But then we should identify one issue as the primary one in which we're planning to track and fix the problem. From what you write it sounds like this should be issue247.

We usually do cross-referencing both ways prominently in the summary, so that we're less likely to forget resolving the subordinate issue when the primary one gets resolved. I've updated the summary here and will update the other issue next.

Adding a reference to issue247 where we identified exactly these orderings as the source claiming solvable problems unsolvable. There's a more thorough discussion of our findings so far and possible solutions. We could consider closing this issue in an attempt to clean up the issue tracker, but I don't mind keeping both issues active as a reminder that we should do something about this.

If two landmarks are derived predicates and one derived predicate is dependent
on the other one, lm_rhw can detect a greedy-necessary ordering between them,
even if they first become true in the same state (since the second one is
derived from the first one). For example this happens with the following derived
predicate from the psr-large domain (where unsafe is also a derived predicate):

  (:derived (affected ?x - DEVICE)
        (and (breaker ?x)
             (exists (?sx - SIDE) (unsafe ?x ?sx))))

I think the example would even work if unsafe were not a derived predicate; the
problem is rather that the greedy-necessary ordering is detected over possible
achievers which can also be axioms:

The lm_rhw code (landmark_factory_rpg_sasp) detects landmarks with greedy
necessary orderings over shared preconditions of possible achievers, and
considers "actual" operators as well as axioms when getting all possible
achievers. While this is ok for finding new landmarks; when detecting orderings
we would need to distinguish between actual operators and axioms.