Whilst this is high risk for a flamewaresque HN policy violation I'm going to attempt a response.
When a very important email never arrived I suddenly realised I hadn't been receiving email for two days. Jumping onto the migadu site I found a brand new UI with all my regexes gone and my email ingestion broken. So I patch it up quickly and send a support ticket.
In short the response to the ticket was: "we had a storage layer failure [...] we could not serve all the requests [...] The catchalls and aliases have been a consequence - hence no announcement" (announcement is a reference to me asking why I wasn't emailed to tell me).
Unfortunate things happen, I get it. However. When they do, notifying clients should be a high priority.
Combine that with some previous and subsequent tickets that were closed without resolution and I have a pattern of behaviour that is completely absurd for the provider of a vital service.
The account that given in your post is at odds with what I received from the support team - this is even more evidence to me that migadu is not the right company to be responsible for my mail.
I also feel its important to highlight your claim "we have never had an outage where mail was lost". When an email responds to a sender indicating that a user does not exist the result is the email being deleted. Many terrible systems in business do this silently. The fact that migadu allowed this failure mode without a mitigation (and in your example, deliberately) is assuredly mail loss. What else could be done? It could be rejected but still saved (bulk disk writes with simple metadata - anything) so that intended receivers can be notified which senders now think they don't exist.