I dare you!

...try to set pointerdown, pointermove, and pointerup to a generic node and then try to drag it around ... I tell you already you will fail unless you don't change the currentTarget per each event...

Actually...it seems that the main problem Andrea was seeing here (in his strangely confrontational Touch Events for IE Mobile rant) would be fixed by appropriate use of setPointerCapture - remember, touch events have an implicit capture model, while pointer events have an explicit capture model.

Check the source code of the basic test and try to replicate the same behavior with your PointerEvents logic and in a cross Mobile browser way ... I dare you!

After you failed trying to do so...

As for the "in a cross Mobile browser way" you'd also reintroduce the touch events handlers he has in his original test (omitted here for clarity, but apart from duplication - which is unsurprising, as we're talking about a different event model altogether - this would not have any impact on the code).

And yes, for older devices/browsers using touch events, I'd advocate using actual touch events rather than shimming. It's unsurprising that you lose performance if you try to emulate a whole different events model in a 5+ year old device running Android 2. Shimming any new tech there will result in pain...this is not specific to pointer events, and orthogonal to the argument that pointer events are inherently flawed. At that point, it's a question of implementation for performance in older browsers, and nothing to do with whether or not a new technology has merits or problems. The rest of the argument seems mostly philosophical: whether it's better to fork/duplicate code for mouse and touch (adding separate event handlers) or to register a single set of event handlers (for pointer events) and then forking/duplicating code inside the handlers, which path leads to more simplicity and ease for developers, and how interaction models are so different that they can't be handled with a unified event handling model.