Should touchmove really always be synchronous and cancellable?

Hi,
http://www.w3.org/TR/touch-events/#list-of-touchevent-types says that
touchmove is synchronous and cancelable.  However many browsers sometimes
choose to send touchmove asynchronously and ignore calls to preventDefault.
 For example, both Safari and Firefox send touchmove events async (with
Event.cancelable=true) during scrolling but then ignore calls to
preventDefault - eg. continuing to scroll freely.  See [1] for details and
tests.  Do you agree that such UAs technically no don't conform to the spec
here?

Assuming there was some easy vehicle for publishing updates to the
TouchEvents spec, would we want to relax this to give UA's the freedom to
send touchmove async and set cancelable=false?

In the interim (or absence), should UAs that choose to violate the spec and
send touchmove async ideally set cancelable=false to make it clear to the
application that they can no longer suppress scrolling?  I've seen this
cause a bunch of confusion which manifests itself on Firefox as "the double
handling problem" where touching and dragging on a page causes some page
action AND scrolling to occur at the same time (eg. perhaps the page was
waiting until some offset was exceeded to test direction and decide whether
to suppress scrolling and perform their action).

I ask because we're continuing to explore [2] relaxing chromium's unique
(and somewhat draconian) touchcancel on scroll behavior.  If we are going
to send some touch events async I believe we should set cancelable=false to
make it possible for apps to understand the difference.

[1]
https://docs.google.com/a/chromium.org/document/d/12k_LL_Ot9GjF8zGWP9eI_3IMbSizD72susba0frg44Y/edit#heading=h.nxfgrfmqhzn7
[2] http://crbug.com/346693