Indeed, our mission is to make it as convenient as possible to send and receive secure emails. Of course, this outcome (unexpectedly receiving blank emails) was not intended, and we'll see if we can improve the experience.
Rolling out end-to-end encryption in a federated system where it wasn't there before, is hard :) But we're trying to do so, anyway.
Well - note that OP uploaded a key to keys.openpgp.org, and then seemingly forgot about it and lost the private key (or at least they couldn't decrypt encrypted emails, and their email client - not Proton's - showed them as being blank). So it's not a scenario that we explicitly tested for, and not something we can unilaterally fix completely - although we can try to make it clearer for the recipient why the message was encrypted and with what key, of course.
> Well - note that OP uploaded a key to keys.openpgp.org, and then seemingly forgot about it and lost the private key (or at least they couldn't decrypt encrypted emails, and their email client - not Proton's - showed them as being blank). So it's not a scenario that we explicitly tested for, and not something we can unilaterally fix completely - although we can try to make it clearer for the recipient why the message was encrypted and with what key, of course.
OP claims to have no memory of having gone through the steps in the published draft standard. The steps involved are at least somewhat more rigorous than merely submitting a key and address to a database, so I'm leaning toward believing OP and questioning the database, especially since the project appears only to have been started in 2019 so completely forgetting having ever gone through such a process seems less plausible than questioning the database.
Further suspect may be the standard, itself (hence "draft"). Why it doesn't require a domain to publish a policy per address for the domain or at least publish that the domain approves usage of the policy seems a rather large oversight* given how it can break email, so this still leads me to be suspicious of Proton as draft standards should be considered "beta", and passively be explicit opt-in (no prompts - user must dig somewhere into the settings to enable).
* I've only briefly skimmed it, so maybe I missed the part covering this.
It's possible that some software did it on their behalf; I believe GPGTools submits keys to keys.openpgp.org, for example. (However, I don't know what the UI flow looks like, it's possible that it could be made clearer what.)
Also, the WKD draft has nothing to do with what's going on here. KOO is not the same thing as WKD, and is not in beta. It's a key server, and the concept of key servers has been around for ages. (WKD has been quite widely adopted as well, despite being only a draft, but that's an orthogonal discussion. It would definitely be better if it became an RFC.)
Somehow, I think either we are reading different articles or one of us has a severe reading comprehension problem. I reviewed what the author wrote and the links and read through the Proton document, and I can't figure out where I have a conceptual error, because the document states WKD, which means the published protocol must have been used or the protocol violated, which what you are describing would be out of spec from the protocol.
Rolling out end-to-end encryption in a federated system where it wasn't there before, is hard :) But we're trying to do so, anyway.