Thread scheduling being the way it is, I don’t think you’ll be able to claim “various canvases render at the same framerate” unless you also synchronize the display. In a multi-canvas page, all it takes is for one or two of the commits to sneak past the VSync for this to no longer be true.
In your summary document, you identified the need to have a backpressure mechanism to throttle the animation and avoid accumulating a rendering backlog. Later in the document, you talked about the negatives of throttling setTimeout/setInternal because it prevents the worker from doing other, non-rendering work. I agree with these goals.
In the call-commit-without-yielding approach, when are you going to institute the backpressure mechanism? If the answer is “at commit time”, then this would prevent the browser from scheduling non-rendering work on the worker during this time, which is one of your goals. Since the user agent has no idea how imminent another commit would be, it would be forced to hold one canvas commit, but not another, further eroding the desire for canvases to update at the same framerate.