Merged.

If Silvan is happy, feel free to merge.

Looks good to me.

You can find the code at https://bitbucket.org/jendrikseipp/downward/pull-requests/97 .

Sounds good.

I agree with all your points. 

For the IPC I actually added a TRACK variable to the portfolios, which could have 
one of the values ["opt", "sat", "cbo", "agl"], but all the code ever tested was 
whether we are running an optimal portfolio (since these use a different code 
path) and whether TRACK=="sat" for deciding whether to stop after finding the 
first plan.

I like the "--portfolio-single-plan" option since it is a backwards-compatible 
change. Shall I implement the feature this way?

Having a way to use the same portfolio in anytime mode or single-plan mode could
be useful, although I'm not sure how often one would want to use exactly the
same portfolio for these two purposes. (I'd expect portfolios designed for
anytime planning to include some sort of cost adaptation etc. that is not needed
in single-plan mode. But perhaps this could be handled in a generic and useful way.)

Not a big fan of making the optimal portfolios more complicated by adding
bound=BOUND everywhere for no good reason. What is the use case? I don't think
satisficing vs. optimal portfolios is the interesting dividing line. The
semantic distinction I see is single-plan vs. anytime. Running a portfolio
designed to produce optimal plans in anytime mode makes no sense, so I'm not
sure I see the point of making them support anytime mode -- any such use is
likely to be a user error that is likely to double the runtime. (First, find the
optimal plan, then run the planner again trying in vain to find a
better-than-optimal plan.)

So: the proposal makes sense in principle, but not yet sold on the details.
Also, is setting the maximum number of plans really a useful distinction, i.e.,
do we ever want a number other than 1 or unbounded here? Supporting an arbitrary
number here also requires changes in the search code for things like iterated
search. I'd be happier with an "--portfolio-anytime" or
"--portfolio-single-plan" option. Either way, it's a bit of a hack, and a
parameterized portfolio would be a cleaner option. But don't let the better be
the enemy of the good here.

Currently, the driver only supports portfolios designed for the optimal and 
satisficing IPC tracks. In principle, we can run portfolios for the agile and 
cost-bounded IPC tracks using the code for satisficing portfolios, but this means 
that we don't abort after finding the first plan. This is a minor problem for the 
cost-bounded track where we just waste compute resources, but a bigger problem 
for the agile track where searching for multiple solutions can result in a lower 
IPC score, depending on how the times are measured.

Therefore, I propose to add a --portfolio-max-plans option to the driver.

If you like the idea, in a different issue, we might even think about whether 
this new option allows us to get rid of the distinction between satisficing and 
optimal portfolios in the code. If I see it correctly, we would only need to add 
bound=BOUND to all configurations in optimal portfolios.

What do you think?