Closing this. Once we're further with the component interaction code and can hopefully simplify the design of the PerStateInformation class, a logical further step would be to improve the design of reuse in the evaluator computations, i.e., the task that is currently served by the EvaluationContext class. But I think this old issue is to unspecific to help us with this. I think what we really want is a redesign in the context of the new code architecture, but this will be another issue for another time.

Quoting Malte (https://bitbucket.org/jendrikseipp/downward/pull-requests/58/issue535/diff#comment-24332693):

"I think it's a good idea to avoid all the copying and merging of preferred operators that happens currently 
[...]. Not sure what the best place for the information to live is. Conceptually, it would make sense to me to 
store [preferred operators and similar information] in EvaluationContext and to make that class "resettable" 
(i.e., allow some form of assignment) so that every search engine can use a single reusable evaluation context 
rather than generating new ones all the time. The current code is quite wasteful w.r.t. performance, but we 
decided to live with for now because the old code was so broken and it's a step in the right direction."