The most elegant solution is not to do it. Do the split up into bytes explicitly and send byte by byte. This way it's clear in which order they are transferred. The solution you described just works if you don't cross endianess borders.
As sending the longs is a hack anyway I would just send them.
The WireData.h Library works well for transmission/reception of structure data without any problem for endianess.
This is simply not true, at least if we're talking about the same library. There's no handling of endianess in this library so any transfer over platform boundaries (and no, the UNO and the Nano are not a different platform, they even use exactly the same processor) will fail for multi-byte types.
When the following experiment between UNO-1Master and UNO-2Slave indicates that the Master has sent the most lower byte (0x78) first and the Slave has received that byte first, there is still an endianness problem? All of our common Arduino Learning Kits (UNO, NANO, MEGA, DUE) are of little endian architecture.
All of our common Arduino Learning Kits (UNO, NANO, MEGA, DUE) are of little endian architecture.
This is correct but the Due is an ARM architecture which is bi-endian, so the endianess depends on the compiler used (or even it's switches).
But for example the AVR32 architecture uses big-endian byte order and is used for some Arduino-IDE compatible boards.
The OP asked for an elegant solution. So either handle that explicitly (so the code documents byte order) or transfer everything in network byte order (which is equal to big-endian byte order).