Yes. Álvaro would like to have the possibility to easily combine shrink
strategies, and I think this is now easily possible with the change of this
issue. We can still open a different issue for integrating any kind of composite
shrink strategy (be it sequential or not) when it comes together with a use case.

Oh, you just answered. Well then, we agree to leave this out for the moment
being. I then close this issue.

The use case of the composite strategy is for combining the own-label shrinking 
for unsolvability with bisimulation. Someone could make the case for (perfect) 
bisimulation + f-preserving shrinking but I doubt anyone will use that in the 
near future. 

So I agree in that there is no use of adding shrink_composite without 
integrating own-label shrinking first.

> In case you vote for adding such a composite shrink strategy,
> I'll attach the two files.

In general, I think it's better to only add things like these once you want to
use them, and from what you write I think you agree? If not, I'm happy to go
with what you prefer.

No performance changes:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue666-v1-issue666-base-issue666-v1-compare.html

In contrast to what I thought, there is no real need for an iterator that
returns the whole tuple <TS, Distances, HR>, because in nearly all cases, the
index is required, hence an iterator over the "active" (i.e. non-merged) indices
of the FTS is sufficient. This also means that the interface of shrink
strategies still takes an FTS and an index.

I changed the shrinking interface as you suggested, Alvaro. I also tested a
composite shrink strategies that simply sequentially applies several shrink
strategies. I don't know if this should be added to the default, however,
without any use case from the literature, because this seems somewhat specific
(no intelligent way of combining those strategies, simply running all of them to
achieve the same goal). What do you guys think? 

In case you vote for adding such a composite shrink strategy, I'll attach the
two files.

For the rest of the changes, see here:
https://bitbucket.org/SilvanS/fd-dev/pull-requests/18/issue666/diff

Devil's issue :-)

This is part of meta issue567.

The aim is to provide an iterator for iterating over entries (TransitionSystem,
Distances, HeuristicRepresentation) of FactoredTransitionSystem. Furthermore,
the shrink strategies' interface will be adapted to have a public virtual shrink
method that takes such an FTSEntry, rather than the current indirect way of
getting the FTS plus and index and calling the private virtual
compute_equivalence_relation method.