This isn't _that_ weird actually.
There are 2 issues here which can cause this behaviour.
Gtk-gnutella (like most other gnutella clients out there) use swarming to improve download speed. That means it tries to get a part of the file from every client hosting that file.
Of course, there can always be someone lame who says it has the file while it actually is another (corrupt) file. So avoid that people get a corrupt file as well gtk-gnutella will overlap a small piece of data between requests to improve the chance the files are indeed the same and not a fake file.
If the overlap doesn't match, gtk-gnutella will backoff a few bytes. In other words, it throws away a piece it has allready downloaded and tries again to see if it can find a match now. In the worst case, it could happen a download is at 99%, and a mismatch happens. If the corrupt file got in around 10% it will actually backoff till it is at 10% again (that is where it should find a overlap match again)
To make sure the file you downloaded is correct, every file on gnutella is provided with an SHA1 hash. This file
must match the file gnutella has downloaded, otherwise gtk-gnutella will throw the file away (actually, it is moved to the Corrupted directory) and start all over again.
What gtk-gnutella still lacks to prevent this is tigertree support (see also the
Call for help page)
Hope that clears it up a little bit.