Well, first. I will be submitting a C "reference" library for all nostr cryptography operations including nip44 to paulmillr hopefully in the next few months, that maybe they can include in the repo.
Yes I agree the nip44 spec can be quite confusing, and build heavily assuming managed runtime with extensive libraries are used. I found it difficult to translate the operations into binary and allocation free, (I would like to target hardware signers in the future)
I think I'm missing your concerns. Are you arguing mainly for the lack of privacy that encrypted messages could theoretically be distributed to whoever asks a relay nicely. Then yeah, concern for me to, but I believe that's the intention of the network at the moment. I believe you also are concerned with "metadata" regarding the nip-01 "wrapper" message containing the PM?
Finally, would have to think some more, but I would argue removing the relay portion would remove the "nostr" part altogether. I don't believe we intend to assume nostr PMs are meant to be ultimately private, but rather a reliable and ideally uncensored way to get private message content to others. I'd argue there is very little privacy in the entire nostr protocol, it's not in the design yet.
I agree nip42 is just trusting the relay. Not a good solution for end-user privacy. I want more privacy but man I can barely keep up as it is. I'm generally a low/no dependency dev, I get nervous when discussing technically complex solutions as wrappers. It allows for easy mistakes and common configuration errors. I think if we come up with a "solution" it should be part of the protocol, not relying to heavily on other "complex" oss communities. I know that sounds bad, but lately imo awesome lists are probably 60-70% abandon-ware and it's getting sad out there for oss. I've had to overhaul plenty of projects in just the past 4 years because I used a "popular" library that became abandoned. Seems way more common in front-end.