Ok. I'm back from holidays... time to work on this. Maybe we discuss this all due to the fact that I don't really understand the combinator approach and why this should be a combinator (i think this is similar to a decorator in old school GoF-pattern-terms). Shouldn't implementing stores subclass this anyways? If we still want it to be a decorator i will recommend to constraint the type to a trait (which probably cannot be sealed, sorry for the confusion) which is the parent class of all other types (like PartiallyIterableStore, CursoredStore, and so on...) such we can support implementors with basic implementations and define serialization (otherwise i fear that implementing SplittableStore requires in-depth Hadoop-knowledge if we use it as a way to do splitting in the Cascading tap). What do you think?