The correct way to accomplish what you want is to either throttle or debounce your searching such that you reduce the amount of requests made in the first place.
1) because clients throttle connections. Suppose a user wants to navigate, you may need to be able to cancel in flight requests or the next page load might be significantly delayed.
2) file uploads can have potentially gigs of packets that haven't been sent yet, which you definitely need to be able to cancel.
If those can corrupt state then you're already at the complete mercy of the network... which is never a good idea regardless of whether this proposal is accepted or not.
Doing ad-hoc hacks around the lack of cancellation seems like a pretty big practical issue to me[1], so I'd certainly like to see something like this spec in the standard.
(Note: something like, not necessarily exactly this. I haven't thought about it deeply enough to be able to properly evaluate the spec.)
[1] Happens all the time when doing simple Ajax-on-futures where you really just want to ignore any result if the operation gets canceled in the UI before the response arrives.