Fantastic job on your lib, ended up going down a rabbit hole due to this bug within .Net:

Jun 26, 2014 at 2:48 PM
Please vote to have this bug fixed:

It affects any use of Touch and WPF.
Jun 26, 2014 at 3:11 PM
Thanks, voted.

I've had to recommend to clients to move to WinRT for future touch apps (which has its own challenges) since Microsoft hasn't been showing WPF Touch any love. The Surface SDK is badly broken on Win8 and many touch controls are not available in WPF. There are also still issues with high rate touch screens like 3M and Perceptive Pixel overloading the WPF Stylus input stack (which touches go through). NativeTouchDevice in Blake.NUI fixes this a bit. I have a Win8 update to it but haven't pushed it here.
Jun 27, 2014 at 2:27 PM
Thanks to your work, I was able to resolve performance issues with higher throughput systems. We can comfortably handle 20 plus touch points simultaneously using WPF. You use an event for dispatching that can be made a delegate, in addition there are a couple API calls that you're using that slow things down further. Because touch handling is synchronous all the way up to the GUI when you implement your own TouchDevice, care has to be taken to make the chain of handoffs as lean and fast as possible.

We now have our WPF Win8 optimized version of your lib, with a workaround to the ReportUp bug, in addition to enhancements to resolve turning off/on various Win8 touch visualization features.

That said, the ReportUp bug affects WPF in general, even if you do not create your own TouchDevice! I suspect this bug is responsible for much of the quirkiness of WPF touch services. I think Microsoft tries to work around some of the issues under the hood which have the net effect of shutting down touch periodically. A fix to the ReportUp bug is essential to make touch viable for those that just want things to work without having to go to the extreme of implementing a custom touch layer with a bunch of odd workarounds.

Microsoft needs to realize that WPF isn't going away. Until most aspects of WinRT can be used from a desktop application, it can't be positioned as the shiny new way forward. WinRT is too constrained by Microsoft's business model considerations and thus intentionally sandboxed to a crippling degree. With some modest tweaks to WPF (making parts of its internals native), it could be made to look shiny and new again. WPF is a productivity monster after all.