Can you please explain what you claim to be a bug? I can't see that. The
keyserver returned a garbled packet, gpg detects it and returns an error.

Okay, I see your point. But then I'd suggest that gpg for starters shouldn't
allow to import that corrupt key into the public key ring.

#v+
$ mkdir /tmp/g
$ chmod 0700 /tmp/g
$ env -i GNUPGHOME=/tmp/g gpg --keyserver hkp://subkeys.pgp.net --recv-keys 715FC6D7
gpg: keyring `/tmp/g/secring.gpg' created
gpg: keyring `/tmp/g/pubring.gpg' created
gpg: requesting key 715FC6D7 from hkp server subkeys.pgp.net
gpg: /tmp/g/trustdb.gpg: trustdb created
gpg: key 715FC6D7: public key "NextGen$ <nextgens@laposte.net>" imported
gpg: [don't know]: invalid packet (ctb=2d)
gpg: read_block: read error: invalid packet
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
$ echo $?
2
$ env -i GNUPGHOME=/tmp/g gpg --list-keys 715FC6D7
pub 1024D/715FC6D7 2001-01-15
uid NextGen$ <nextgens@laposte.net>
uid NextGen$ <nextgens35@laposte.net>
uid NextGen$ <nextgens@freenetproject.org>
uid Florent Daigni�re <florent.daigniere@utbm.fr>
uid Florent Daigni�re <florent.daigniere@laposte.net>
sub 4096R/61C04699 2006-11-11 [expires: 2007-11-11]

$ echo $?
0
#v-

Just tried it. gpg imports the parts of the key which are clean and ignores the
garbled stuff. Thus you see the invalid packet message while importing but
after exporting the key and importing it again you won't get that error message.

I don't think that gpg should return success when importing this key. After all
an error occured and that should be signalled to the user. gpg would also etun
with an error if there has been any other problem with a keyserver. The fact
here is that the keyserver has sent a garbled key and thus it is a bug in the
keyserver.