It was so that you could make multilayer games using the link cables.  You could send a byte (0-255) to the other calculator which would recieve it if it was in get() mode.  You could set up a system where the calculators would be sending bytes back and forth that represent things like keypresses or positions, and have a multiplayer game set up.  I made a couple of games using this as a test, but mostly Basic was just too slow to handle the stress of having to take into account an extra player.  I made a few simple things like two players could move around on a screen and shoot things at eachother, but nothing ever was finished.

Well the send( command took a number as an argument, which could be any real from 0 to 255.  The get() command would return either a value from 0-255 in ans, or -1 if nothing was being sent at the time. 

Yeah, and there was also a feature to have it wait indefinetaly for an incoming byte.  Once you get the calcs syncted up, it makes things a lot easier

Linking is easy.  Syncing is hard.  Really, no matter what routine I write for linking, it is up to the programmer to write code that will properly synchronize the calculators.  Lets say you need to send some critical data from calc A to calc B.  You have to send the byte, but calc B might not be ready to receive a byte, so you have to keep sending until calc B sends a confirmation byte back to calc A. When time is critical, you have to be very cautious about how often the calcs check to see if there are incoming bytes.  It needs to be frequent enough so there aren't long delays between sending, but sparse enough to not slow down the program.

Could interrupts be suited to the task?
Implementing interrupts in Axe would be phenomenal.

Its even more horrible on the NSpire: you can't take out the batteries. The calc auto-shuts down before you have the time to do it.

I assume you all mean that when you press the on button, it breaks the program.  Unfortunately this is nearly impossible since you'd have to break out of an unknown amount of subroutines and the stack would not return the program to the home screen.  Now, I could implement something that saves the stack size and creates an interrupt for exiting when the on button is pressed, but it would take up probably around 200 extra bytes or so and be very complicated.

You will be able to poll the [on] key as a direct key input though, so you can always manually check if it needs to exit.

I have a feeling that if I do implement interrupts, it will be towards the end of the development.