I do not pretend to know what's going on underneath, I'm no expert, still consider myself a relative newbie here, we don't get to see all the magic happening underneath.
But I am presuming that the chan c issues is down to the following:
1) chan c declares a channel 'c' in scope across both pars to all threads 1 to 4
2) Each of the threads receives not a channel but a chanend see the prototype
3) The compiler seeing the par{} construct and the passing of a channel performs magic on the channel including initialising the channel and passing and end to to each thread in the par{}.
4) But maybe this isn't initialised when the compiler passes the ends to threads 3 and 4 and as such is in an unusable or illegal state.
The compiler should therefore catch this and produce and error or realise how its being used and makes sure the channel is in a state ready to be used for the second par{}.
But I'm guessing of course, maybe it does this and something else is causing your issue Mika.
However being able to define this in the Par{} scope would make it all much clearer.