Messages are guaranteed to arrive in order.
And the significance of that statement is void, if you appreciate the obvious fact that there is no guarantee as to which order they are transmittet in, since both messages are triggered off the same event, but by two different addons - you cannot imply any order to the sequence of event handlers (i.e. you don't know if HealComm or CastComm's event handler will be called first).
HealComm isn't the only library that should be allowed to add additional data if CastComm allows additional data to be added to events.
IMO You can get everything else you need from the API.
The test you made, merely compares the differences between using
1) string.sub in the receiver
2) instanciating a new array for each message received, while also using string.gmatch and string.gfind.
Of course no one would write the receiving end so stupidly - basically you're comparing a well designed inflexible solution (1) with an extremely ill designed flexible solution (2). I find this scientifically flawed.
For a well designed flexible implementation it's entirely plausible to use string.sub for any message as long as you define the length in characters for each field. There are probably other methods too, that would make it just as efficient and fast, and you cannot just pop in a naive approach and compare it like that.
I don't care to discuss this matter anymore, you can keep CastComm the way it is, it's a nice library, and it serves it's purpose well. I'll keep HealComm the way it is, it serves it's purpose equally well.