Here are two CLs corresponding to the two options above.  I haven't tested any of them, I will ask someone expert in Android app on Chromebook (Dennis?) to check them while I am away on vacation for next two week.  And feel free to grab this bug if needed.

Option A:
https://chromium-review.googlesource.com/c/619175
A straightforward fix but not ideal because a touchpad drag is not the same as touch drag.

Option B:
https://chromium-review.googlesource.com/c/619176
Looks like idea but the extra state in EventForwarder needs a careful look.  Is there a chance the state could be uninitialized?

Bumping up the priority as per the internal bug.

I have updated the wheel-event patch but it doesn't seem to solve the problem.

The biggest pain is to find out the problem: debug logs don't show up /var/log/messages

Can we make this issue easier to reproduce/test by just plugging a USB touchpad into an Android phone (taking ARC++ out of the loop)?  I remember testing touchpad scrolling on Android in the past this way.  Or is this unusual touchpad behavior a quirk of ARC++ in particular?

It's a quirk of ARC++ in particular.  I tested a Blackberry Priv touchpad last week -- it goes through a different event type, and does and has always worked fine.  See https://bugs.chromium.org/p/chromium/issues/detail?id=483231 for when we made some changes to support the Blackberry Priv flow.  ARC++ invented their own separate mechanism for touchpad without knowing the prior art, but now they feel they can't move away from it because they've already told some developers about this event stream.

Looks like this was reported a long time ago in  issue 704051  - duping into that.