Your example falls apart if the algorithm ordering is crc32(sha256(input)).
Not quite. A collision found part way thru the stack still allows you to generate collisions across the entire stack, because you can skip the inner-most steps.
e.g. if we have
crc32(sha256(y)) = crc32(someValue)
if crc32(someValue) collides with crc32(anotherValue), then there is essentially a full stack collision, because you can literally ignore the innermost sha256() function when generating your X11() collisions.
This is partly related to the nature of using a hashing algorithm for PoW - it's unnecessary to have a collision attack at the inputs, only somewhere along the hashing chain before the output.
Of course, this is all mainly about future-proofing - but in the long-term, I think this may end up being highly significant.
this coin is broken?
Completely and utterly. Abandon ship! I'm such a nice guy that I'll buy your worthless DRKs for $0.01 so that you can at least get SOMETHING...
Heh, I'll up the ante and bid $0.02.

I fail to see how this discussion could generate fear or the notion that X11/DRK is broken... Any hash could have collisions, which one are you afraid of?
The real question is, soemtimes science WANTS collisions to prove a point... How long is the string that the hash is applied to, rests at the bottom of the collision argument tree. If you apply it to a 1chr string, derp, lotsa collisions there no matter what hash you're using... This is what essentially makes rainbow tables possible, passwords that are typed are relatively short. Moore's Law is rapidly causing the typed password to become questionable because it shrinks the entry string...
It would seem that the algos chosen are chosen for a reason...