Filing tracking bug for discussion/consideration of a FIXME found in animation logic. This is a known issue that appears to date to ~2014, see comment in 

http://crrev.com/189883003

The issue will persist with SPv2, excepting that rather than querying stale compositing state via PaintLayer direct compositing reasons, we'll be querying stale paint property tree state via transform/effect paint property node direct compositing reasons.

On consideration we currently believe that the SPv2 situation is roughly analogous to SPv1 and that it is possible a cancelled animation could stay on the compositor longer than necessary, but is otherwise not harmful.

Why are we calling canStartAnimationOnCompositor() from cancelAnimationOnCompositor()? I would think we could use compositor state booleans on the Element instead of relying on the can-start logic to essentially reverse engineer whether we did-start. Perhaps the compositor state booleans are potentially stale, or complicated by the potential existence of multiple animations for a single Element?

If we can't use the compositor state bools then as the comment states we'll need to postpone the animation cancellation until at or after the appropriate lifecycle stage. Which means we'd either need to accrue a list of the animations to be cancelled somewhere and call that when appropriate, or post a message to process them later (which I'm told is done in other similar circumstances via some existing infrastructure).