Salomé, you're right, I think this issue has been resolved with issue108. If you
want, you can mention it in issue207, but since it's already resolved, I don't
think it's strictly necessary.

Patrik has also mentioned issue198 as related, where I think the only remaining
open point is the cleaner handling of multi-path dependence. We're planning to
look into that one soon.

I think this one can be closed. :-) I'm changing the "assigned to" flag to mark
that it was resolved by Salomé, not me, just for the record. (Not that we do
statistics on this or anything.)

Did the implementation of heuristic caches (issue108) fix this issue? Either way
it would also be good to include it in the revise search code meta issues (issue
207)

Malte - you are right about garbage being used (actually, it's the value for the 
last state that was evaluated, but that's close enough to garbage).

Lazy search does not store multiple heuristic values either, but I think it 
doesn't reopen nodes either, so there's no problem there.

Just a note: This seems to be much related to issues 198 and 207.

If I recall correctly, our current (eager, and possibly also lazy?) search code
has the following properties:

1) It stores *one* heuristic value in the search space. If multiple heuristics
are used, then it will only store one of them.

2) If reopening is enabled, it does not recompute heuristic values but uses the
ones stored in the search space.

Since the search space only store the value for one heuristic, this probably
means that reopening together with multiple heuristics leads to garbage being
used for all but one of the heuristics. (Wild speculation: does that only arise
in eager search? If yes, maybe that's part of the reason why the parameter tuner
preferred lazy search over eager search so often?)

(See email conversation with Patrik on May 31, 2012.)