Turns out I needed to handle serialization of strings explicitly, which fixed the error. Looking at how class_name_type is handled throughout the source it seems its type is set in stone, furthermore it seems I pay at least an additional 128 bytes per exported class type, I guess this is convenient when serializing in text format for easy viewing, but for use cases where memory is at a premium and a hash would suffice it would be nice if this type was configurable throughout the system. I'm guessing this string is used in the extended_type_info system mentioned in the manual, leading me to believe that the lookup table for exported types uses a costly string compare to find the correct derived type. Neither performance, memory use or archive size is mentioned as a specific consideration in the manual amongst the 11 goals, leading me to believe perhaps the library simply isn't suited for domains where these are of importance? This I would find rather sad, especially since this is areas where the language is often used.