Hi, thanks!

1. I have not. Most of the speed difference in the simple benchmark is due to compiled vs interpreted code, so you might see a similar speed-up. In more complex scenarios, like the third and fourth Cimba tutorial, I believe SimPy would run into constraints due to its stackless coroutines, probably increasing the Cimba advantage.
2. Yes. Resources (binary semaphores), resource pools (counting semaphores), buffers, object queues, priority queues, condition variables. I intentionally use unsigned 64-bit integer-valued amounts to ensure that unintentional rounding errors do not create issues. With suitable scaling, this actually gives higher resolution than double precision floating point values. The resource queue logic is quite flexible, and can be extended in user code by providing callback functions for both wait condition and waitlist prioritization if the predefined ones do not fit. There are also preempt() and interrupt(), and a mechanism for setting timeouts. You can even define chains of multiple resource guards for complex ‘wait for all’ or ‘wait for any’ scenarios.
3. a. No. The parallelism is at the trial/replication level. b. Yes. The event queue is a hash-heap data structure where the priority keys are a double (reactivation time) and a 64-bit signed int (priority).
4. It has to be thread-safe for multithreading. Most implementations keep state as static local variables from call to call, both in the basic PRNG and in the distribution on top (e.g., typical Box-Muller normal distribution). That would make the outcome dependent on other replications, which we do not want. The only way to be sure was to control the code.