eddy9:
Why does Udp behave as I described above?
It's not conventional UDP behaviour, but comments on another thread make me suspect that the shield is trying to resolve the outgoing address at the start of the packet, and your experience suggests it is buffering the outgoing data until it can transmit it. Neither of these strike me as desirable things to do, but it seems to be implied by the behaviour you're seeing. I would be interested to know whether packets that you sent while the recipient was offline are sent spontaneously when the recipient comes back online, or are only sent when you try to send a subsequent packet to the same recipient.
eddy9:
What is the proper way to correct his behavior? Knowing that I really cannot guarantee that there will always be a device connected the Ethernet Shield to receive UDP packets at power up.
Your workaround seems reasonable to me. I would not like to have the shield buffering and then delivering historical packets after some unknown and uncontrolled delay. Presumably the shields buffer capacity is finite and there's no telling what would happen once the buffer is full.
eddy9:
Is my solution to the problem appropriate, that is, is it going to cause some issues down the road since I am calling Udp.begin() in the main loop instead of Setup()?
My only reservation is that you are triggering it based on the return value from Udp.endPacket(), but the current documentation for the Ethernet library does not document a return value. If the library implementation you're using does actually provide a return value and it indicates that the packet was transmitted, you should be good to go. Does Udp.beginPacket() have a return value in your implementation?