"I also showed that data sharing is so slow with ithreads as to be useless. real processes certainly perform better than ithreads in about any scenario"

As far as I can see you only (if at all) showed that preemptive threads (in particular ithreads) pay for the added comfort with a speed penalty. Which is not really surprising. Any form of preemptive multitasking needs at least some form of locking or synchronizing that costs speed

BrowserUK showed without question (the copying of the data to non-shared to make only one use of that data can't be better than simply using the value) that your implementation of the ithreads matrix mulitplication could be faster, so the comparision was definitely unfair. This may have been an oversight by you, it may possibly not really change the end result in any significant way if done correctly (who knows), but it still makes any conclusions from your results at the moment impossible

No denying you make some excellent points (IMHO). I don't like the penalty on everyone so that ithreads can be used, I don't care much about performance on windows, I wouldn't miss anything if ithreads would be replaced completely by an implementation with forks. But I also think that comparing ithreads to Coro (or simple linear execution) in a worst case szenario is not the way to go if you really want to convince a lot of people to drop ithreads. Coro is very useful for programming user interfaces or other tasks with lots of I/O. But its inabilty to use more than one core makes it it an ill fit for CPU intensive tasks in todays landscape of multicore CPUs. Preemptive and nonpreemptive multitasking simply have different use cases today and if you had compared ithreads to the API-compatible forks module it might have had a lot more relevance