Something else, then sends that to the other AirTalk, which then “unboxes” the packet and passes it to the other Mac.
That's pretty much exactly what AirTalk already does to 'smuggle' AppleTalk past APs that don't speak it. The problem is deeper and harder to fix, unfortunately: all the AppleTalk protocols basically request a fixed amount of data at once (this is a simplification but it'll do here). So, let's do a bit of a thought experiment. We'll pretend that sending back a chunk of data takes 100ms, that the query takes 1ms, and that the network link has a latency of 1ms. So it looks like this:
- Computer A asks for a chunk of data (1ms).
- Computer B waits for the request to arrive (1ms latency), then sends the data.
- Computer A waits for another 1ms (latency) for the first part of the data to arrive, then 100ms for the data.
- Repeat from beginning
In this world, a chunk of data takes 103ms to transfer from computer A to computer B.
Let's transfer this same chunk of data over a network link with latency 50ms:
- Computer A asks for a chunk of data (1ms).
- Computer B waits for the request to arrive (50ms latency), then sends the data.
- Computer A waits for another 50ms (latency) for the first part of the data to arrive, then 100ms for the data.
- Repeat from beginning
The total here is 203ms! We've nearly halved the amount of data that has been transferred per second just by making data take longer to get from one end of the link to the other.
Try thinking of it like this: imagine you're having a conversation with someone by letter, but your letters can only be a fixed length (like an aerogramme or something). If you'd been having this conversation for a while but it suddenly took twice as long for the letter to get to its destination, you'd be able to have less conversation in a given time.
TCP deals with this by allowing the size of the chunk of data to change to adapt to changing network conditions: so if you're on a high-latency high-bandwidth link, the amount of data you can send before the other end has to explicitly say 'got that, please send the next bit' can be much higher. So you don't need as many round-trips.
In our letter analogy, that is like - letters take longer to arrive, but we can write a longer letter, so we can still say all we need to. But AppleTalk can't do that adaptation, all the letters are fixed length. So the only way you could really fix this in all cases would to be to build a time machine, because it'd need perfect knowledge of the future.
edit: it's also worth adding that things like HD video streaming pre-download a big chunk of video to smoothe out variations in the network and to hide the latency problem. This option isn't available to AppleTalk (and also isn't available to me at work, where I wrangle sending
live video over the Internet; and at that point one becomes very aware of the tradeoffs).