Ok, so a few things:
Your "unicast" is basically TCP. If e1.31 unicast is indeed implemented with no-ack, it uses optimistic delivery. That means the sender assumes the packet got there ok and will not resend the packet unless it hears otherwise. A no-ack packet is a packet that a client sends back to the sender with essentially a list of packets it believes it did not receive. In your analogy, that means you'd send a reply back to the sender which contained a list of letters you were suspicious never got delivered.
I appreciate the explanation but I didn't need the analogy :-P. I was asking about specifics of the protocol. I'm not clear why a unicast e1.31 would ever want reliable transmission. By the very nature of DMX, at some point you are going to be retransmitting packets that are out of date for the current timing frame. If multicast e1.31 is indeed more reliable over 802.11 (which I still find hard to believe as a multicast frame is sent first as an acked unicast frame to the AP and then rebroadcast as a multicast frame by the AP), why not just remove the no-ack requirement in the protocol? Transmission would revert to best effort (just like multicast) but you'd still get the routing benefits of a unicast frame.
Might have to read the protocol tomorrow after my morning cup of coffee.