gnupg detection of zero-octet encrypted mpi

[vedaal]

question about the 'mpi too large' error issue :

have examined the 'problem' form of a secret key
http://www.angelfire.com/pr/pgpf/keypicGU.html
with pgpdump,
as well as the 'safe form'  http://www.angelfire.com/pr/pgpf/keypicGS.html

pgpdump clearly identifies the zero octet in the beginning of the encrypted
secret key packet:

here are the pgpdump results for the key form that causes the error message
of 'mpi too large' :

Old: Secret Key Packet(tag 5)(928 bytes)
Ver 3 - old
Public key creation time - Thu May 23 14:41:06 UTC 2002
Valid days - 0[0 is forever]
Pub alg - RSA Encrypt or Sign(pub 1)
RSA n(2048 bits) - {not included in post}
RSA e(5 bits) - 11
Sym alg - IDEA(sym 1)
IV - 98 61 5a b5 79 4e 00 4f
Encrypted RSA d(2045 bits) - 00 61 ff .. {remainder not included}
Encrypted RSA p(1024 bits) - {not included in post}
Encrypted RSA q(1024 bits) - {not included in post}
Encrypted RSA u(1023 bits) - {not included in post}
Checksum - 3e 32
Old: User ID Packet(tag 13)(24 bytes)
User ID - keypic

the pgpdump results for the same secret key 'safe' form with the passphrase
changed, shows the following for the Encrypted RSA d packet:  Encrypted RSA
d(2045 bits) - e5 87 dd .. {remainder not included}

as this is easily detectable, would it be possible for GnuPG to
use -gpg --listpackets
automatically, as a 'screening' test before importing a keypair, or secret
key, or after changing a passphrase ,
and alert the user 'not' to import the 'problem' key
{with an 'override' option available, for those who wish to investigate
further}

also,

does the 'mpi too large' problem happen only when the 'first' encrypted mpi
packet of a secret key, begins with a zero octet,
or can it happen when 'any' packet, (even not in a key, but in an encrypted
file), begins with a zero octet?

tia,

with Respect,

vedaal