I may be misreading this, but it seems to me that the major problem of gesture recognition is being punted to the client.
Having spent a fair while doing touch-based work (DS, iOS, effectively similar problems like wii remote gestures and game controller combo recognizers), the main problem beyond gesture detection is determining which gesture the user intended. The classic example is double tap; if you want to accept double tap as a gesture, you cannot process a single tap until you're sure it *isn't* a double tap.
What this means in practice is that unless the double tap's action is compatible with the single tap's action, you have to delay accepting the single tap. In general, this winds up meaning that your interface is laggy; it has to wait for the longest applicable potential gesture before confirming an action.
Unless I'm totally misreading this, uTouch seems to "fix" that by simply shoveling a giant pile of events at the client and saying "meh, you figure it out".
I know this is a hard nut to crack, but surely we can do better than this?
The main solution I've worked with to date on this is in iOS (everything else I've worked on was handrolled gesture recognition built on raw data streams), and the iOS solution isn't great. They let you register gesture recognizers and chain them in priority order, so you can say things like "if you get a tap and it isn't a double tap, give me a single tap" and it will handle the delay internally. They also have a "cancel" mechanism where it will occasionally say "Oops, that touch I told you about a moment ago? It was part of a gesture, you should totally disregard it...".
That system is... ok to work with, I guess. Passable. Usable. That's about as far as I'll go, though.
uTouch doesn't sound to me like an improvement, which is unfortunate.