I apprecited the post of runnerup so I decided to work on his suggestions. The result is leOS 0.1.4 (look at the first post for the package).
It uses a Struct to manage the tasks but it doesn't use other suggestions runnerup told to me, i.e. dynamic memory or other fixes, because of the memory consumption. So the actual library is (I think) the best tradeoff between simplicity/clearness/readability of the code and firmware size (and my C/C++ skills 
).
runnerup:
Why don't you make a 'task' struct. That would be a more intuitive approach in your library because you would only need one array instead of four or five distinct arrays for each task.
Done. With the leOS_2_tasks example, the code has grown from 2390 to 2424 bytes.
Why don't you allocate the array(s) to dynamic memory so that you can resize it in addTask() (and possibly removeTask()) as necessary.
Not done. Too much over my programming skills. And, I think, too much Flash-eater. Remember that leOS can run over little Attiny MCUs.
In your source there are two places where you slide all of the array elements over to fill in a gap (in removeTask() and ISR() interrupt handler when cleaning out one time functions). I recommend you either break the common code out into a common function or just call removeTask() from ISR(). It will make your code easier to read and it will do magical things to your code size.
Not done. The ISR routine is hard to manage. To call external functions you have to work a lot (i.e. using "this" and pointers to it) and the final size of the sketch grows of about a hunder bytes more. So I dropped it.
Thanks a lot to runnerup for his interest in my little library.