Encourage more consistent semantics of Touch.identifier?

Hi.
TouchEvents v1 defines
Touch.identifie<http://www.w3.org/TR/touch-events/#widl-Touch-identifier>r
as:

identifier of type long, readonly An identification number for each touch
point <http://www.w3.org/TR/touch-events/#dfn-touch-point>. When a touch
point becomes active, it must be assigned an identifier that is distinct
from any other active touch
point<http://www.w3.org/TR/touch-events/#dfn-active-touch-point>.
While the touch point remains active, all events that refer to it must
assign it the same identifier.
*No exceptions.*
This leaves a lot of freedom to the implementation.  In particular, in
Chrome we use the current touch count starting at 0 (i.e. touch, release,
touch, release has identifier=0 in both cases).  Mobile safari appears to
use a global counter of some sort (eg. the same sequence will have
identifier=x and x+1 for some x).  What do the other browsers do?

It's possible (though clearly "wrong") for applications to behave
differently as a result of these different implementations.  Eg. I didn't
appreciate in advance the impact this difference would have on a simple
touch test program I wrote http://www.rbyers.net/paint.html (though in
retrospect it's obvious).  Is anyone aware of this difference impacting any
real-world apps?

In general I prefer specs to over-constrain things like this to minimize
the chance of app compatibility problems.  Any chance we'd be willing to
encourage or require (eg. in a later version of TouchEvents) a more
specific behavior?  We're willing to change Chrome (desktop and Android) to
use the global counter approach instead if it'll result in better
cross-browser consistency.  Then again, if no real-world app has actually
been affected by this, then it may not be worth the effort.  There may also
be even greater opportunities to improve cross-browser consistency
elsewhere.

Thanks,
   Rick