Thanks Robin2 for your contribution to the discussion. Let me answer your last question first. I guess the answer is 2µsec. The pulse is between 1000 & 2000µsec resolved to 4µsec, so measurement resolution should be at least twice as good as that. Given that the pulse has two ends, that means accurate to 1µsec at each end.
Going back to your first sentence - "what is the purpose of all this?" - I am struggling to expand on what I have said already. I'm sure it's a diversion to go into the "business logic" of how that information is used after it's gathered, but basically radio control gear is telemetering six off eight bit values at a repeat rate of 50 samples per second.
Either I have not understood the pinChange interrupt, or you have not understood what I have been writing about interrupt latency. I would really like to shake that out. I have been using Arduino Uno, Nano and Pro / Pro Mini. They all have Atmega 328 processor. That has one 16 bit counter, and only one external pin to transfer current value to a holding register. Please correct me if I'm wrong. I haven't played with Mega, and don't have one to hand, but it may have more.
Actually, if I did say they all start at the same time that was a mistake. The problem is that they all start at close to the same time and can finish close to the same time. That may mean that they can start or finish at the same time, but it doesn't mean that they do necessarily start or finish at the same time.
Isn't it true that if I use pinChange interrupt, I can only get a time stamp using some code of the interrupt servicing routine that's stimulated by the pinChange event? The time relates to when the interrupt servicing routine executes, not the state change on the pin. The variability of elapsed time between the two is the issue.
From observation on my oscilloscope, if I "OR" the receiver outputs the result brackets all individual channel pulses. Pulse length is variable, but not greater than 2.4msec and it should not be less than 1msec, because any contributing pulse shouldn't either. These pulses come along about every 19msec. I could use an "and or invert" eg 74HC4086 gates to measure, say channel 1 at first cycle, channel 2 on the next, etc. I would then get around my 6 channels in 6 * 19 = 114msec - so I'm telemetering updates at about 9Hz. Alternatively, I could commit a separate Arduino to each channel & get them to talk to each other, or I could do something in between. Two Arduinos could get around the cycle in 57msec, 3 could in 38msec.
My disappointment is that the old receiver delivered a nice train of pulses that I could easily and accurately measure to about 500nsec. I'm pretty sure that pre 2.4GHz transmitters sent a train of PWM pulses, and their receivers did the same. My first 2.4GHz receiver delivered this train. My next receiver, which looks identical, doesn't. Ideally, if it's still common practice to deliver individual channel outputs from the receiver sequentially, I just want to get another receiver which does that and scrap this "orphan" receiver.