Well, the idea behind the 'version' field was specifically to detect cases where the older version can't cope with the newer one. That is, merely adding new optional fields which can be ignored should not result in bumping up the version. However, adding compression type and using a different compression type results in a file which is plain incompatible with the old version, which the 'version' field is specifically supposed to protect against. In the case of lzma, yes, it would abort anyway, but what would the user see? A CHECK() failure with a coredump. With the version field, the program would cleanly show the error with the right message (unsupported version). Also, what if that would not be 'lzma', but some dumb insensitive algo without any checksums? It's better to always go with the generic "don't trust the algo" way and use the version field the way it was designed to be used. It does add some additional logic, but that logic is just a couple of lines of code, and it was designed to be like that from the start.