Maybe you're right. However, this should not about individual persons / projects... this is more about that I'm still uncertain, why so many experts cannot get this thing right by just working together finding a suitable solution :-) There must by more than one way of solving this.
I'd argue that he is right about the fact, that the "driver" (libinput) should not send "simulated" events, that are not really there. Whereas the cursor movement should defintely stop the scrolling behaviour, the driver is not the place to care about this, I think it is more a compositor / window manager thing, but I'm not an expert.
However, if he would implement an opt in solution (2 config options) for lets say:
libinput.simulateKineticScrolling=1
libinput.kineticScrollingSpeed=0.22
scrolling itself is a simulated event. So is any two-finger gesture that isn't directly represented as an affine transform from one pair of coordinates to another.
As long as they are marked as being synthetic, why not?
If you mark them with a "this is a synthetic event" bit, the compositor/windowmanager has all the information it needs to decide whether or not to ignore the event (because, for example, the pointer moved out of one window and into another).
The driver generates the synthetic events, the compositor/windowmanager decides whether or not to drop them. Done.
This is such a trivial thing to fix, you just stop sending scroll events when the cursor moves.
Peter has done a great job on libinput for the most part, but he is 100% wrong about inertial scrolling (and button remapping, among a few other things).