Nice work, it's good to see someone doing some really systematic researching here.
I've tried in the past to find and fix the problem, with no success. My researches also ended up with bafflement, but I think I can at least tell you what appears to be going on even though I know no way of fixing it.
My most significant experiments concerned a Calico pet, freshly adopted in Petz 3. The first part of the experiment went like this:
I adopted the pet and then immediately closed the game. This results in a pet which still has no YALP section -- incidentally, look at YALP backwards and it reads PLAY
I saved this pet and put a copy into the P5 game's Adopted Petz directory without the Calico breedfile in place. Open game, close game, no play at all. Game writes to petfile immediately.
At this stage, the pet which had been in Petz 5's Adopted Petz directory already had become unusable in Petz 3 or Petz 4.
Right, I took copies of Jesterp3 and Jesterp5 and chopped each into 4 chunks which I happen to know from experience are the best way to compare petfiles:
Part 1 from start to the first p.f.magicpetzIII which comes below the .lnz section.
Part 2 from that p.f.magicpetzIII to the next.
Part 3 from that next p.f.magicpetzIII to PfMaGiCpEtZIII ( start of the Family Tree data )
Part 4 the rest of the file; this is only family tree and picture.
In this untouched petfile, Petz 5 had immediately written an extra 196 bytes into the end of part 1; these bytes were all hex zero. It had also altered 4 bytes, which are presumably checksum info. Petz 5 had written an extra 4 bytes into the end of part 2; these bytes were also all hex zero. Part 3 remained untouched. Part 4 contained 64 extra bytes in the family history area; these were all hex zero at this time.
The picture remained unchanged -- it does not get changed until a pet is put away or some significant change occurs. When that happens, the bitmap becomes much larger and 24-bit colour instead of the 256-colour that Petz 3 expects.
Later work with the same file produced nothing that was any more helpful really; after a while data got written into those areas, not just null bytes, but I was unable to figure out how to remove them such that Petz 3 or 4 could use the file.
Incidentally, placing a petz 5 pet in a Petz 3 or 4 Adopted Petz directory does _not_ corrupt the pet; it can still be used in Petz 5 because the game does not actually touch the petfile, it only reports that it's "corrupt" as far as Petz 3 or 4 can tell. What happens is that the game checks the Adopted Petz directory every time it starts up and, when it sees a file with the extension .pet, it checks to see if it can be used. If it can't, it simply tells you that the pet file is corrupted and doesn't even try to write to it. Check it out, you can put a small text file into the Adopted Petz directory, call it test.pet, and the game will report:
Error while trying to load Adopted Petz file: Data Corruption
File = \Adopted Petz\test.pet
When in fact you know for sure that the file isn't even a pet file. The message is just a form of error-trapping, to prevent crashes.
Hope this helps, and I wish you the very best of luck in your researches!
Cheers
Carolyn