This version mixes up three distinct phases: rewrite from scratch; redesign; own microkernel.
While Okuji initially might have intended a direct port of the existing Hurd code, by the time I started following Hurd development (2004 IIRC), it has been long clear that Hurd/L4 is a rewrite from scratch.
The next phase was the desire of Neal and especially Macrus to completely reinvent the design of the Hurd. This was mostly fueled by Shapiro's influence, resulting in a security-above-everything rage. It was in this phase that not only the original L4 has been abandonend, but also all thoughts about using newer L4 variants (which might have been suitable) were forsaken in favor of Shapiro's Coyotos.
The whole idea of redesigning the Hurd -- especially for security concerns -- is highly controversial: I always strongly objected to it; and Marcus later admitted himself that he got carried away and lost sight of what really matters for the Hurd. (But only after realising that Shapiro's notion of high security is fundamentally incompatible with the GNU philosophy.) I opted for not explicitely mentioning this aspect in the FAQ at all, as it's impossible to explain properly in a compact form, and probably impossible at all to do it in an objective fashion.
The final phase -- following the realisation of incompatibility with Shapiro/Coyotos -- was the attempt to create new microkernels specifically for Hurd's needs. Marcus abandonned his pretty soon, and never made it public, so I didn't mention it at all; but Viengoos is still relevant in certain ways.
BTW, my original text also more explicitely answers the question what happened to the Coyotos port -- which after all is what the title promises...
All in all, I still think my text was better. If you have any conerns with it, please discuss them...
<cjuner> Does anyone remember/know if/why not seL4 was considered for hurd-l4? Is anyone aware of any differences between seL4 and coyotos?
<antrik> cjuner: the seL4 project was only at the beginning when the decision was made. so was Coyotos, but Shapiro promised back then that building on EROS, it would be done very fast (a promise he couldn't keep BTW); plus he convinced the people in question that it's safer to build on his ideas... <antrik> it doesn't really matter though, as by the time the ngHurd people were through with Coyotos, they had already concluded that it doesn't make sense to build upon *any* third-party microkernel <cjuner> antrik, what was the problem with coyotos? what would be the problem with sel4 today? <cjuner> antrik, yes I did read the FAQ. It doesn't mention seL4 at all (there isn't even much on the hurd-l4 mailing lists, I think that being due to seL4 not having been released at that point?) and it does not specify what problems they had with coyotos. <antrik> cjuner: it doesn't? I thought it mentioned "newer L4 variants" or something like that... but the text was rewritten a couple of times, so I guess it got lost somewhere <antrik> cjuner: unlike original L4, it's probably possible to implement a system like the Hurd on top on seL4, just like on top of Coyotos. however, foreign microkernels are always created with foreign design ideas in mind; and building our own design around them is always problematic. it's problematic with Mach, and it will be problematic with any other third-party microkernel <antrik> Coyotos specifically has different ideas about memory protection, different ideas about task startup, different ideas about memory handling, and different ideas about resource allocation <cjuner> antrik, do any specific problems of the foreign designs, specifically of seL4 or coyotos come to mind? <antrik> cjuner: I mentioned several for Coyotos. I don't have enough understanding of the matters to go into much more detail <antrik> (and I suspect you don't have enough understanding of these matters to take away anything useful from more detail ;-) ) <antrik> I could try to explain the issues I mentioned for Coyotos (as far as I understand them), but would that really help you?
<mel__> did people consider to port Hurd to Darwin? i.e. replace GNU Mach with Darwin? <braunr> no <braunr> well, quickly only <mel__> wouldn't it be a reasonable idea? <mel__> after all, Darwin is production-ready and contains a Mach side. <braunr> not more than fixing gnumach itself, or using linux instead <mel__> well. <braunr> those implementations have diverged with time <mel__> i see <mel__> the fsf should pay people for fixing gnu mach then. :) <antrik> mel__: indeed someone consided Xnu (the actual kernel of Darwin) a while back; but I think he shelved the idea again. not sure about the exact reasons <antrik> Xnu implements a few improvements that might be helpful; but it doesn't address the really fundamental issues that matter for a true multiserver system...