I can see how you would leave the receiver in the dark by sending them the original, deferred message, but how would asking the sender's device to resend with a different key not result in a notification?

Furthermore, as soon as the sender attempts to deliver another message to the recipient, they would get another notification (because the encryption key changed back to the real key); alternatively the attacker could continue blocking (and reading) messages to the recipient, but the lack of delivery would be noticeable.

You could escalate it into a MITM rather easily, though, by attacking both ends; but again, a key change notification should be displayed to both parties.

Assuming the closed sourced app works as advertised, obviously.

Well, what you are describing is a regular MITM attack. Unless you validate fingerprints, this is a risk with _all_ public key-based protocols.

So they can recover the messages, right? However, wouldn't these messages still be encrypted? Sure, they force a key change, and the messages are encrypted using the new key and sent. Theoretically, an attacker could have multiple copies of the same message, but these messages would still be encrypted under a variety of different keys right? Wouldn't the content of the messages still be secure?

Unless the key-change forces the user to be using an insecure key-pair, but is that actually happening?

> but whether WhatsApp servers report to the device that the message has been delivered

It is hard to check what WhatsApp does, but in Signal it is not the server, but a recipient who sends delivery receipt. WhatsApp then has to either recognize encrypted receipts or allow only one-way conversation during attack. Carrying out the whole attack just to decrypt "hi, are you here?" is not really interesting.