That certainly was quick.
I've been looking through the source code, and I must say it looks quite well-written. My comments so far...
1) Allowing multiple tasks to have the same priority complicates the scheduler implementation. Since there is no mechanism that guarantees "fairness" in the situation where there are multiple tasks at a given priority (such as time-slicing or round-robin within a priority level), I don't think much is bought by the cost incurred. 2) There are no timeouts on wait operations. The projects I've done in the past have all had situations where waiting on a semaphore or event flag with a timeout was extremely handy. Any thread doing communications with the outside world is likely going to have requirements like:send message
wait up to X ms for reply
if reply received then do this else do that
Being able to place timeouts on semaphonre/event-flag waits allows requirements like that above to map directly into source code without having to create two threads to handle the if/then/else condition.
If you do have to create separate threads (one to wait for an event, and one to wait for a timeout), then you have to use more mutexes/semaphores to coordinate the actions of the two threads, and you have to have mechanisms for one thread to abort the wait operation of another thread. It gets messy and hard to maintain.
Since you've already got a per-task countdown timer, adding an optional timeout on wait operations shouldn't be difficult. 3) If I were using it, I'd probably change the build process so that the kernel is built separately as a library, and then linked with application code.