Hi Jack, thanks a lot, I'll make some tests this afternoon (CET timezone here) and let you know.
You are totally right when you say that is impossible to achieve exactly the same behavior across different engines, it's very true, but that is also out of the scope of my lib. It would (teorically) require to handle manually any low level aspect of the rendering process, and this is exactly what I do NOT do with Tweene, at the end of the process the single tween is always demanded to the engine of your choice, so it goes out of my control.
The aim is to offer to developers a more standardized approach in their work. You can think at it like web standards work with browsers. You can use the same language (CSS) to define styles for any browser, and in most of the cases you will also achieve the same visual result, but there are also a lot of cases handled differently by different browsers, because they run different rendering engines. Without a standardized CSS language, you would have not only different rendered results, but also to learn different style languages and different approaches for different browsers, which is clearly a worse scenario. With Tweene I'm trying to offer a common language and achieve the more reliable result in most of the common cases, not to solve any differences in the inner animation engines.
For example Tweene supports also CSS Transitions. As you obviously know, you have no guarantee that two or more transitions of same duration will really end at the same instant, so it is basically impossible to guarantee a perfect sync while it's not an issue in gsap in which all things are in perfect sync by design. I cannot solve this and I don't want to. It's out of my scope. Let' say a developer writes a simple animation using Tweene and CSS Transition as inner engine. Later, that developer comes to the idea that achieve a perfect sync is a requirement for that work. It can just switch the engine from "transit" to "gsap", and in most of the cases no more efforts would be required. I think it's a better scenario than rewriting the whole thing having to learn a different API too. If its animation implies also some corner cases due to the internal differences of the two rendering engines, those differences would be there to solve in any case, with or without Tweene.
Said that and coming back to timelines, as you can imagine my implementation of timeline on top of different engines that I cannot control at low level can work only as an advanced "scheduler". Basically I organize the whole thing as a doubly linked list of simple tweens (well, the real structure can be more like a graph, but the list probably gives a better idea of the concept). This approach clearly introduce some small delays on "keyframes" on the timeline, while in your native implementation of timelines this is handled perfectly without any additional overhead. I know, there are of course implicit limits in this approach, but again, if this is an issue for the user, he can choice the tweene's gsap driver that relies on your native timeline implementation, he will have just a really small overhead before the very first play, after that the animation is totally powered by your lib.
Since I cannot obtain a cross-engine perfect sync, I tried at least to obtain always the same order of execution of different items (tweens and callbacks) and that was the point of the pause issue. A user talked to me of a simple scenario: a sequence of different tweens one after each other (no overlapping) with a pause just at the end of each tween. With my "timeline as a scheduler" I can do this so "complete event > pause > begin of next tween" are intrinsically always executed in the same order, while the inner optimization that you perform inside your code for events that happens inside the same tick (which is totally a feature from a performance point of view!) made difficult to me to achieve the same order of execution.
As told, I'll try today your changes and let you know. Thanks a lot again! (and sorry for my bad english)