One real world scenario I encountered while testing coracle is that if only nip-44 is implemented this is not backwards compatible with nip-04. Not sure at all about NIPs best practices, and if this is best addressed at all in NIPs, SDKs. I think @hodlbod had thought this through on coracle, and there was some bug he squashed to make these DMs NIPs compatible.
The way I see it working is: 1. Have all the major clients and SDKs support encryption and decryption for both NIP-04 and NIP-44 for some time but have NIP-44 be the default for encryption. 2. Clients can allow users to migrate their signed NIP-04 encrypted events by decrypting them and creating new ones with identical content but encrypted with NIP-44. 3. Once most people stop creating new NIP-04 encrypted events, remove support for encrypting in NIP-04 and support only decrypting NIP-04 moving forward. NIP-44 becomes the only way to encrypt events.
NIP 04 is used all over the place still, including DMs, can you describe what you're seeing in more detail?
Coracle handles backwards compatibility to nip-04 fine, no issues with Coracle. I mentioned to Terry that some apps may still use nip-04, and not nip-44. Therefore if new apps build only nip-44, without taking into account backwards compatibility this would be a nostr interoperability or #nostrability pain point.