Simplifying sequential() / parallel()

[Brian Goetz]

> One of the design principles for this API is that parallel transforms
> will not be automatic. There is a parallel() method for that. This
> hasn't changed, right?

Correct.  Parallelism is always explicit.

> It seems to me that the ground rules are changing, driven by some latent
> aspects of the implementation. But I'll have to see if/how these changes
> affect my sample code before I can respond.

No, it has nothing to do with the implementation.  It was identified 
that complexities in the model -- which were no longer as important 
because of other past simplifications -- could be removed, making the 
user model and specification simpler.  As often happens, this also makes 
the implementation simpler and more performant, but that's a secondary 
benefit.  The reality was that the existing sequential() / parallel() 
were overly general, complicated, and did not admit efficient 
implementation.