I am afraid I have to say that there was a the bug of gsflib optimization, which would wipe necessary ROM data unexpectedly. The condition to cause the glitch might not be very common, but it might wipe the ROM data (especially a sample) quite slightly without being noticed.
Oh, you used counters. I never used counters in my coverage system, I just used boolean values. I also designed it so that there were two fields per coverage granularity of RAM regions. One field marked if it was read first before being written, the other marked if it was written first before being read. First field set would protect the other from being written. ROM is a little easier, since there's no write check to be done, heh. (This applies to my 2sf optimizer, and the USF code coverage tools I added to my lazyusf2 library.)
The reason I used counters for the coverage is because I wanted to detect the loop count for the song length writer (option -t -T, I always overuse it for time-saving).
@loveemu Did you happen to notice when doing DKC3 if it sounded like the gain had been turned up an insane amount. Seems to be doing this since the GSF plugin version 3.0
Reoptimized every my gsf sets (excluding 4 earlier sets, since I want to redo the entire process for them, when I am motivated.) Now they are optimized with slightly loose paranoid parameters, to protect scattered unread samples.