I think I can answer most of this, although I didn't write the serialization code.

On the JSON format, I think this is because our serialization implementation is generic over the Serializer, as most serde implementations are. So we don't provide specific code for JSON in particular, we just tell serde how any Serializer should interpret our data: as a linear Sequence, with some "metadata" about the shape (and a version number). serde_json is then responsible for turning this into a JSON representation, specifically.

Yes, I think that processing time of "discovering" the shape on deserialization could be expensive. In particular, think of it this way: if we know the shape of the data independently, we can grab a block of uninitialized memory of the exact size we need and then iterate once through the data itself to fill it in.

I think the version field is a sort of humble admission that we're not going to write "the one serializer to rule them all" the first time. You can consider a whole slew of optimizations and enhancements: including whether the data is (approximately) C- or F-order, packing arrays of bool into smaller representations with a bit for each element, etc. You may need a different "version" of the serialization format for these changes.

Lmk if that answers your questions!