I originally wrote the "zero copy" support in proto2, long before I created Cap'n Proto. What Protobuf means by "zero copy" is much more limited than what Cap'n Proto means. Protobuf's "zero copy" applies only to individual string (or "bytes") fields. The effect is that when you call the getter for that field, you get a pointer to the string inside the original message buffer, rather than a copy allocated on the heap. The overall message structure still needs to be parsed upfront and converted into an object tree on the heap (which I count as a copy).

Cap'n Proto is very different. Every Cap'n Proto object is actually a pointer into the original message buffer. Accessing one element of a large array is O(1) -- the previous (and subsequent) elements don't need to be examined at all. Similarly with structs, each field is located at a known fixed offset from the start of the struct, so can be accessed without examining other fields. Protobuf inherently cannot do this; there is no way to know where a field is located without first parsing all previous fields in the same message.