If you are in Germany, the country of Sauerkraut and Beethoven, and you move far to the east, you might arrive at the town of Dresden. In this city, the Dresden University of Technology (TU Dresden) is located, which's operating systems group has developed a C++ implementation of Jochen Liedtkes well-known L4 µ-kernel interface. This microkernel, ironically called Fiasco, is the center of all the different projects of the TU Dresden Operating System (TUD:OS) research group.

I'm not rooting for or against microkernels, but here are my thoughts on your points:

The first one is that in reality, you have to trust more than only the kernel. A bug in the disk driver can very well crash the whole system. Sure, it cannot overwrite data in other processes directly. But it doesn't have to - in fact, other processes *ask* the disk driver to transfer *their* data.

Everyone should know that a microkernel does not itself ensure that code is trusted, or that code does not need to be trusted, or that flaws in code will have no serious impact. All that is ensured, is that memory and resources will be compartmentalized between drivers. However, some people do seem to (erroneously) imply that microkernels make the kinds of guarantees you described! But of course this aspect of microkernels, while having many benefits, is still a far cry from being a silver bullet.

The second issue is that all processes run in parallel. This mixes up the order of events during processing . . . The once-so-simple code has to be modified to make it possible to enforce a certain order in actions. This is in sharp contrast to the goals a microkernel tried to achieve: Lots of simple and maintainable modules, glued together to create a working whole.

Once again, some people can be seen as implying that microkernel systems are dramatically simpler than monolithic systems, which is a misconception. What is mentioned above is indeed one of the major caveats in implementing a microkernel. However, there are solutions to this problem, that keep things relatively simple once implemented. The real problem is that its hard to avoid taking very significant performance penalties when solutions to synchronization issues are implemented. IIRC, the Hurd had this problem, and is trying to curtail such performance penalties by tailoring their system specifically for Intel x86 architectures.