This information is out of date. I'm not certain of the system the official client uses to store these packets, but I'll attempt to explain what I've discovered -

The 10-byte header is in every packet you receive of this type. However, The size values have an extra 4, 8, or 12 bytes, depending on things....
The first WORD is the total number of bytes in the list (plus 12).
The second WORD is the number of bytes in this set of entries (plus 4 or 8 or 12, depending)
The third WORD is the number of bytes written thus far, not the number remaining. It also has a plus, depending)
The fourth WORD is the rank of the first entry on the first set, and some unknown value on subsequent sets of the same list.
The fifth WORD is null.

The "Message Data" DWORDs only show up on the first set. After that, they're not there. If they are there, the length values for the current packet are +8, if not, +4, and if it's the only set in the list, +12. I don't quite understand the logic behind it, but that's what it seems to do.

After this follow some entries, though not necessarily the "number of entries", unless it's a short list. The Flags values are, in actuality, bitwise, using 0x10 for Dead, 0x20 for Hardcore, and 0x40 for Expansion. The character class can easily be determined using Flags AND 0x0F. The Title values are the act the user has beaten, starting from 0. Note that all normal characters count as Act 1 (0), and act 5 doesn't count, just like D2 statstrings. To determine the "Character Title" from this value, you can use the ranges 00-03 = None, 04-07 = Beat Normal, 08-0B = Beat Nightmare, 0C+ = Beat Hell for classic, and 00-04, 05-09, 0A-0E, 0F+ for expansion. Character names are not strictly null padded, but often will contain junk data after the first null byte.

Finally, the server usually sends these in the right order now, apparently, although, of course, you shouldn't rely on it. You can, however, easily sort by the third WORD in the header.

In order to shed some light on any potential confusion regarding the modern format of this message here have been my findings with regards to the formatting. These messages are encapsulated by the MCP protocol so they all have their 3-byte MCP protocol header. The ladder data message always also contains a 7 byte header present in all the ladder data messages. It is as follows:

(Byte) Ladder Type
(Word) Total Size
(Word) Chunk Size
(Word) Data Index

The rest of the message is then:

(void) Data Payload

The Ladder type is the type of ladder. Possible values for this byte are given in the request message documentation here: < https://bnetdocs.org/packet/99/mcp-requestladderdata > The full data payload may be split across multiple of these messages and each message contains this 7 byte header above. The ultimate length of the reassembled payload is Total Size. The Chunk Size is the the size of the chunk of data payload included in this individual message. The Data Index is where to insert this payload chunk into the byte sequence to reassemble the stream.

The Data payload in its entirety is then as follows. There seem to be no short messages at least anymore; no weird length calculations. The Reassembled payload looks like this:

(Dword) first entry rank
(Dword) actual number of entries
(Dword) unknown (always 16)
struct {
(Dword) Experience
(Dword) Zero (may be high dword of exp)
(Byte) Character Flags (Dead, sorceress, etc)
(Byte) Number of Completed Acts
(Word) Level
(Byte) Name[16]
}[actual number of entries]

I say actual number of entries because this varies but it never seems to be more than 16. The (Dword) unknown may in fact be the maximum number of entries returned. I note (Qword) Experience described above is probably two dwords since Diablo II is a 32-bit program. Name is a fixed length 16-byte field containing a null terminated character string followed by enough bytes to ensure the total length of that field is 16 bytes. Remember this is the reassembled payload! This data may be split into multiples of the MCP_REQUESTLADDERDATA reply and may break in the middle of data fields. Once reassembled it seems this structure has no weird length fields, short strings, or sometimes missing headers. My tests overnight indicated the multiple payload messages were received in order but you might not wish to bank on this being the case.