Closing this due to lack of activity.

Looking at LM-Cut tie-breaking remains an interesting topic for those who want to investigate this. There has been some work in this direction published in the meantime by the Saarbrücken group. Note that this doesn't have to be restricted to tie-breaking in general; for example, one could define precondition choice functions based on other criteria than currently (e.g. h^add values).

We should investigate the effect of tie-breaking on LM-Cut performance.

Background:

As issue69 showed, LM-Cut tie-breaking has a significant effect on expansions. 

At some point we made parts of the LM-cut computation incremental, which
affected tie-breaking in such a way that the number of expansions increased in
many domains (not hugely, but noticeably). Overall coverage also got worse due
to a huge coverage decrease in Airport. At the same time, overall search time
decreased in most domains because the speed-up due to incremental computation
more than balanced the increase in expansions.

Scatter plots that show the main findings from that issue are attached. Some
domains with 0-cost actions and very large costs are omitted (also in the plots
TOTAL-*.png that give all data points in one plot) because the configurations
tested in that issue supported these domains only partially or not at all.

Notes for repository divers:

The "good" tie-breaking (w.r.t. number of expansions) was still present in SVN
revision r3613. The "bad" tie-breaking was already present in SVN revision
r5272. The experiments in the scatter plots used translator revision r3613 and
preprocessor revision r5272 for both search code versions.