In the attached test case the duration of the opacity animation should change after approximately 1s due to a duplicate animation item being appended with a longer duration. As a result the box should suddenly get much lighter. Running the test with OMTA enabled however the update occurs after 5s when the original animation item ends. This suggests the change to the duration of an animation is not being flushed to the compositor thread.

After further investigation, it seems like the changes are being flushed but are being applied incorrectly on the compositor thread. When applying animations the compositor thread doesn't do a lot of the checks that are performed when running on the main thread does as indicated in bug 980769. In this particular case we have overlapping animations. Normally, in ElementAnimations::EnsureStyleRuleFor, we check properties.HasProperty(prop.mProperty) to see if a later animation has already set a property but on the compositor thread we don't do that and just overwrite the later animation with the earlier one (since we iterate over the list in reverse).