Cooperative multitasking is, in general, less than optimal in terms of stability. Both kernels run in the same address space, and must voluntarily cede control to the other, so any problem with either writing to the wrong place or failing to yield control to the other can cause a system failure. In addition to that, there is also the latency introduced when Linux has control and receives a hardware interrupt which it must then ferry to Windows for processing. In general, they can't both be running at the same time, which is not the case with all other virtualization methods.
The real strength of this approach I think lies in the total time and manpower required to get it working - the paper on their web site says that from the day he sat down to start the project, it took him roughly one month until he was able to run KDE programs, and the total modifications to the Linux kernel were only a few thousand lines of code. I find this pretty incredible in itself.
Those days in late 2003 were crazy. Waking up at noon to work on it for until 9:00pm, and then off to a night shift writing boring tests script stuff until the morning. And also weekends. It was like a full time job with extra hours during that month. Was full head-on stamina at age 21, and I don't even drink tea or coffee.
Interestingly, if it wasn't for the boring night shift job I had back then, I would have never found all the time back at home during the day time to do all this. And once I figured out how I want to write it, nothing stopped me until it worked.
The real strength of this approach I think lies in the total time and manpower required to get it working - the paper on their web site says that from the day he sat down to start the project, it took him roughly one month until he was able to run KDE programs, and the total modifications to the Linux kernel were only a few thousand lines of code. I find this pretty incredible in itself.