When I first implemented my MsgPack lib I assumed that the spec was complete, however when trying to read streams serialized by other libs, I came to the shocking conclusion that classes were not being serialized as I would expect (using a map). Instead I would get an arbitrary sequence of values (not even wrapped by an array) that should somehow be mapped to properties (in the order those properties were declared. Clearly this is far from a drop-in replacement for XML or Json.

In addition, it would be great if we went beyond what what classic serializers would typically support out-of-the-box naively. In C# there used to be limited out-of-box support for complex types in the Xml serializer (but it did require adding attributes for each possible sub-type). For Json we have to implement some pretty complex interfaces in order to deserialize polymorphic types. Let's take the opportunity to fix that and make MsgPack a first-choice serializer for hirarchical object-model structures.

In my opinion opton 2 should not be recommended as standard. Having to run a file conversion utility during upgrade should really be a novelty of the past. Updates to micro-services should be made possible without the need of down-time. However everyone should be free to make their own assessment for their particular application, and if the small package size was the reason for choosing MsgPack then there probably is a good reason. But this explains why option 2 is the 2nd option rather than the 1st :-)