I think that could mostly work. The placeholder message would have to be of identical length to the original and the resent message would have to use later sequence numbers/message ids (or whatever is used to identify individual messages) so the server couldn't tell that the placeholders were placeholders.

One issue is that it would mean that, in the case of an active attack where the server substituted a key they knew in place of a legitimate new key from the user, the server would be able to decrypt the possibly-placeholder resent message and determine whether the user had notifications on. If the user didn't, they'd know that they were safe to continue to attack the user (this attack is more risky than the passive one on the blocking resend without placeholder messages protocol, of course). So, this does improve the security of the protocol for users with security notifications enabled, at the cost of making users without those notifications less safe. I'm not sure how the tradeoff should be balanced here (just as I'm unsure if the UX tradeoff of having the option of not receiving security notifications is worth it...).

to find out if the user has notification on would be the same as doing the attack, and to find that for all users is the same as mitm all users.

im not sure how is the security of those who dont have notifications on worse in this case then what they have now.

if i want to i should be able to say if somebody changes the key i want to first verify the key before i send the message to that person.

lets say you organise a big protest vs some regime. i know who you are and i know that you comunicate with the number xyz. i redirect that number to my. in the meantime you send me a list of names that are in our group and adresses. i reconect with a xyz number and get the list and everything. even if youbget the notification its to late.