Not and be compatible with the OpenPGP spec. You can define a safe subset of OpenPGP with some additional restrictions (like no weak keys) but that won't be PGP any more, it'll be a new protocol.

Technically true and it would certainly avoid a bunch of confusion if the new subset carries a new name. However there are a bunch of "OpenPGP" implementations out there but when you start comparing them, it's obvious that they differ quite a bit.

PGP doesn't use handshakes because it's mostly used for offline communication.

Then the tool could issue warnings much like the browsers do if the certificate is crap. And/or refuse to work with weak keys for new documents.

Warnings are unfortunately worthless without enforcement, much less adequate presentation. GPG doesn't even bother to prominently warn the user when a key is expired: they tuck the message below the "verification succeeded" message, which is the exact opposite of what they should be presenting.

If the key was valid back when the message had been signed, and the key wasn't revoked later, what's wrong with verification having succeeded?

As the original analysis notes: many of the keys weren't valid at message signing time.

I think you misunderstand how PGP works. There's no real-time interaction between participants. Participants don't have certificates, only keys. The ciphers and signing algorithms are determined by the OpenPGP spec rather than some negotiation between parties.

The trust model in PGP isn't a certificate with a signing chain but a "web of trust". I know Alice and Alive knows Bob. Alice vouches for Bob by signing his key and giving it to me. Since I trust Alice personally I have some level of trust in Bob.

Yes, but the issue of a key being weak (using a compromised cipher, having too little entropy, etc) is orthogonal to how the actual communication works. If your key is weak for any reason, the encryption and signatures of your messages may be worthless, and that's what warnings should be about. Also, on incoming messages, if they have the same problem, there could be at least a warning about the key not being secure enough/cipher being old or compromised. I'll decrypt the message, but beware. That kind of warning.

The difficult part, of course, is that since there's no official approved way to have a remote/online keysigning party, communicating newly-generated keys to others in a trustworthy and secure way may surely prove to be a problem.

PGP (by which I mean GPG's OpenPGP implementation) will show you the type and size of a public key. It can't tell you that they have a shitty password or have their private key password printed on their t-shirt. When you receive a message the session key was encrypted with your public key so it's only as good as your key.

You can check out an encrypted message to see what symmetric cipher and digest was used. While GPG could throw up a warning there's nothing you can do about a weak symmetric key or digest. There's no return channel to the sender and no handshake.

In the case of signed packages the issues of poor digests is more the fault of the repository. They are the ones that need to enforce the digests and asymmetric key types they support. They could easily reject MD5 signatures and small public keys.