REPL: null-values in parallel ranges?

I'll try an overview:
A sequential collection now inherits from a parallel collection, this means
 0.) a parallel collection is not a sequential one any more

True. A sequential collection is now a parallel collection.

 1.) therefore, old libraries by design can't handle parallel
collections as input per default.

That's the idea with this redesign, yes. Since the (valid) complaint (it seems to me from most people) is that old libraries would be compromised, this would disallow old code to implicitly use them.

_Perhaps_ a solution to this requirement could be to provide a Iterable wrapper around a ParIterable. If a client wants to violate things in lust for performance at his own responsibility, he would be allowed to do so. A risk would then be explicit in the code.

legacyCallImSureDoesntHaveSideeffects(someParallelCollection.wrapSeq)

 2.) a library writer has to "enable" the use of parallel collections
at each method parameter by requiring "only" the more general parallel
collection type variant if it supports parallel collections

True. If the code within a method can use the parameter in parallel ways, this is expressed through a weaker precondition in the type of the method parameter.

 3.) a library writer should inform the users if he changes a return
type from e.g. Seq to ParSeq because it can be that the user's program
will still be compiling, but now lacks the guarantees the sequential
collection variants give

This is a good point.

If he uses a ParSeq as a return type, the code calling a method may still compile due to type inference. Note, however, that this does not hurt existing libraries, since there aren't any yet. Furthermore, we've had issues like this and we've used migration warnings to make them more detectable.

open questions:
 * foreach stays parallel?

Yes, foreach stays parallel. In ParTraversable, ParIterable and ParSeq its possibly parallel, in a concrete collection class like ParArray it's surely parallel.

 * how to write a library method that can be used both by users
understanding and using parallel collections and others who are
completely agnostic of parallelism concerns without putting the burden
on the user to use `.seq` everywhere to be on the safe side?

In the current proposal, if the library writer knows his method won't do side-effects:

Library writer writes:
def libraryMethod(sq: ParSeq[Int]) = {
 sq.map(_ * 2)
}

User writes:
libraryMethod(ParArray(1, 2, 3))

If the library writer knows his method will do sideeffects in closure passed to the collection argument:

def libraryMethod(sq: Seq[Int]) = {
 sq foreach {
   x => println(x)
 }
}

If the library writer writes a method which takes a closure argument, he would have to assume the closure is side-effecting just to be on the safe side:

def libraryMethod(sq: Seq[Int])(f: Int => Int) = sq.map(f)

IMO the choice to use this design is a conservative one. Users are on
the safe side and old code shouldn't break (even if HOFs like map,
collect, etc. are safe even when they use side-effects) What I still
don't like is that the default `foreach` is parallel. In my
experience, executing side-effects concurrently will produce problems
in more cases than not. For me the parallel foreach is the special
case not the sequential one.

I agree with you that it's easier to make a mistake if a foreach executes in parallel, especially in the presence of type inference.
However, if a reference is known at compile time to be executed sequentially, then there are no risks whatsoever.
A ".seq" or ": Traversable[A]" can always be used to fight type inference.

Although an always sequential `foreach` and an always parallel `pareach` would solve the `foreach` issue, this is just a rule of the thumb. 90% of collection methods take closures and any closure can contain a sideeffect. To be completely safe, all other HOFs would require parallel counterparts as well.

Contrast that to the current solution where the onus is on the user to
make sure to don't use side-effecting closures with  parallel
collections.

In the current solution, the user must make sure closures are pure for any collection.
In the proposed solution, the user must make sure closure are pure unless he knows at compile time that his collections is a sequential one.
This seems like an improvement to me..

Alex