Well, I didn't worry about that. I'm sort of thinking that there is, or should be some cross over in concepts between the two spheres...
Neither policy is mandatory. It just means different outcomes. Postponed differentiation is appropriate when the single/double click outcomes must be exclusive, but the delay is tolerable. Separate response is more appropriate when the outcomes are compatible, since there won't be any delay for a single click.
I'm trying to think of more embedded system style examples, but I'm coming up blank. Need the second coffee for that.
Suppose I have a digital clock, a push button will increment one of the digits in some configuration state... as I push, the numbers on the display increment 1,2,3 etc. and I want that to happen swiftly. I want it to reset to zero if I double press. In this case, there is no advantage to waiting the double click time out before incrementing the display.
If the display currently shows "7", and I respond with a double click, it will first increment to "8", then to "0". That seems fine from a UI perspective so I give the implementation the okay.
You do have to avoid or use deferred response if the single click response can not precede the double - say, a single click will explode some dynamite and a double click will disarm it.