It seems to me it would be MUCH simpler and better to either implement the Mach IPC interface in userspace in terms of POSIX, or as a Linux kernel module, rather than somehow attempting to run Linux drivers in Mach or some other microkernel.
Fundamentally, the Linux driver interface is enornomous, constantly changing, and partially documented, while I guess the Mach or L4 IPCs API are much smaller and well-defined.
Also, the "DDE" layer page only mentions block, network, USB and sound drivers, while of course a useful system needs at least 3D acceleration as well, plus a lot of miscellaneous stuff.
Not to mention that non-driver parts of Linux like the scheduler, MM subsystem, etc. have been extensively worked upon to be fast, reliable and scalable to SMP systems, and I don't see how anything else could possibly compare to that.
If the plan is to do MM and scheduler in userspace, then that's probably not going to be of any real use other than as a toy, and anyone using whatever new feature the Hurd provides will want to do that in conjunction with at least the Linux kernel-mode scheduler and MM so that things will work at decent performance and scale properly to SMP systems.
And of course, that way Linux users would be able to just run the Hurd easily along with existing other software.
Again, this assumes that once you get rid of everything that Linux already does (and where there's no chance at all that an userspace solution with much less developers can compete), there will be something left in the Hurd, which I'm not sure whether it's the case.
Oh, and for the record, a monolithic kernel using a managed but compiled language like Java/C# is probably much faster than a multiprocess userspace microkernel system, while having the same isolation and better security (no buffer overflows, ever!) than the latter, so the whole concept of a C-based microkernel-based system might be in fact totally obsolete.
(yeah, this is kind of a trollish comment, but I believe it reflects reality)