Well there are definitely issues here (ordered least significant to most)

• Chrome and WebKit do not return Performance.now as the time when calling the callbacks, but rather return the time from the start of the frame
• Chrome only calls a single queued rAF callback per frame. Calling rAF multiple times (not nested) results in the callbacks running on distinct frames
• The spec is under specific about when to run the sample animations phase. whatwg says “When the user agent is to run the animation frame callbacks”, while the older source says a task should be “scheduled regularly”. Neither of these clarify whether a callback passed to rAF within one frame will apply in this frame or next (this would depend on whether the task is scheduled before or after script is allowed to run I guess). This results in Edge and WebKit/Blink having different behavior, and more importantly, a primary use case of rAF is to wait a frame, and I think the vast vast majority of developers use rAF thinking it will perform the function of rAF rAF.

So it’s fair to say the behavior I’m specifically complaining about here isn’t clearly a bug with WebKit, but I’d argue it’s a bug that the spec is under specific, and I wouldn’t be surprised that if we decided to clarify it in the spec, the logical way to clarify it would be for the task to be scheduled such that when a callback is queued with rAF it will be called on the next frame.