Do routers ever combine multiple small frames into a jumbo frame then split them up again on the other end? I know that most of the time it wouldn't make sense to do because you would add latency by waiting for the second packet to come in, but if you had a QOS backlog it might make sense. Or are jumbo frames always end-end?
Let me see if I am understanding your scenario correctly:
Assuming my understanding of your problem statement is correct, let's see what it would take to implement this.
Let's say the queue on the egress interface looks like this at some instant:
(out) Queue Queue <-------------- Head Tail P1 P2 P3 P4 P5 P6 . . .
(1) Identification: The router would have to examine these packets, check if they are IPv4 or IPv6 (with the fragmentation extension header), then look at the fragmentation fields to identify reassembleable fragments. (Not all packets are IPv4 or IPv6, and the implementation would have to leave these packets alone.)
(2) Transmit order: It is possible that P1, P2 and P5 are fragments of one datagram, and P3, P4 and P6 are fragments of a different datagram. The implementation would therefore have to first reassemble and transmit (P1 + P2 + P5), then (P3 + P4 + P6). Normally queues are first-come-first-served, but now you'd have to "cherry-pick" fragments from across the entire queue.
Also consider what would happen if P5 is not the last fragment of the datagram; so you have to wait till the last fragment showed up in the queue, but in the meanwhile (P3 + P4 + P6) is ready to be reassembled and transmitted, so would you transmit it?
(3) Out-of-order fragments: Note also that it is possible that P2 might in fact be the first fragment, P1 the second and P5 the third. This is because these fragments may have taken different paths on their journey from A to R. Normally, end hosts deal with this situation of out-of-order fragments, but if routers start doing reassembly, this is something that they have to take care of as well.
(4) Checksum recomputation : Another thing you'd have to take care of after reassembly is checksum recomputation. Note that earlier in the routing pipeline we have already recomputed the checksum once (after decrementing the TTL), and now in the output queueing stage, we'd have to do it again after reassembly.
(5) Refragmentation: Another thing you'd have to consider is refragmentation: if in the above example P1, P2 and P3 were of sizes 4000, 4000 and 1500 bytes, and the output interface had an MTU of 9000, would you leave the three fragments alone or would you refragment into two packets of size 9000 and 500 ?
(6) Then finally you'd have to think about performance. All the above processing would have to be done at line rate, i.e. after every enqueue to the queue. For a router that supports even 10Gbps line rate performance you can calculate how fast the reassembly related processing described above has to happen.
In summary I'd say that this is possible in principle, but the practical issues are many. And the benefit does not justify the engineering cost involved in implementing this (read: if you were a buyer, how much more money would you be willing to spend on a router that can reassemble versus a router that can't?). Having said that, if some smart end-user application designer can build an application that can demonstrate superior performance (measured in terms of $$ :-)) by using routers that support reassembly, then it's a different story.