Thank you for the clarifications. Right now only one of those issues concerns me to any extent: the format byte. To present a better case, I tried to think of concrete scenarios where it might lead to complications. I think might have found a not too contrived one, and I wonder how do you see it.
Let's say I want to archive metadata for the tracks of my old Southern Cross competition. Suppose that there are two popular ways of long-term metadata archival: Cas-Stunts and an online ZakStunts database, and that I want to use both, one serving as a fallback for the other. The ZakStunts database would be indexed by a 1802-byte hash, and it wouldn't read the Cas-Stunts binary metadata (at least not directly -- there might be a shared export format, etc.). Now, a natural thing to do would be using Cas-Stunts to enter the metadata and save it in the split format. If I do so, however, the format byte will be changed. Why does that matter? Because if I then add the track to the online database it will go under a different hash than the original TRK, which was available from the competition site up to that point. A pipsqueak who happens to have the old file and tries to check it against the database will get a false negative. Furthermore, I can't even circumvent the issue by writing a tool that creates standalone SMD files, as Cas-Stunts will not load them without the format byte change. If the format byte is not changed, however, there is no possible mismatch. While this issue is more obviously relevant to the split format, I believe it also applies, to a lesser extent, to the combined format as well. Suppose I pick an old, add combined metadata to it, drive a lap on the modified track and extract a TRK from the replay. If the format byte is left unchanged, the TRK at the end of the process would be identical to the original one, which is a small but IMO significant advantage.
In a nutshell, then, I believe the format byte should never be changed by Cas-Stunts. It seems to me a small price to pay for eliminating any potential incompatibilities with other tools as far as the 1802 bytes are concerned -- even with tools unaware of Cas-Stunts, and even when dealing with tracks older than Cas-Stunts itself.
As I said in the beginning, I don't think the other points they bring any more issues. The 32-bit hash question will become a moot point if you accept my main suggestion, but in any case that hash is meant for Cas-Stunts consumption, and other tools won't have to deal with it except when creating or validating metadata in the Cas-Stunts format, so it shouldn't really concern anyone. As for the field length, I first thought of 256 as a generous value (more than three 80-char lines of text!) that would be enough for even quite extended comments. A maximum length of 256 for all current variable length fields would amount to (if I counted it right) a maximum block size of 1086 bytes, almost 10% of the hard limit. It may sound like nothing, but who knows how many extra fields might be added in the future... 64 might be a fine value too, or perhaps there might be different limits for each field.