(Only because I like puzzles, and I like to understand things. I don't think this has much practical relevance, so feel free to ignore it, I don't want to waste your time:)
If we have a `&Mutex<T>`, and `T` doesn't itself contain some kind of `Cell` we know for a fact that:
- someone created a `T`
- someone handed over ownership of that `T` to our implementation of `Mutex<T: Send>`
- at that point, `T` and anything inside it reachable through references could have been read by code inside `Mutex::new()`. That could include niche optimizations. After all, `Mutex` may use an `Option<T>` internally.
- that `T` is still owned by that `Mutex`, otherwise we couldn't have a reference to that Mutex.
- as our `Mutex` doesn't hand out mutable references, we know that no `&mut T` can point to that value concurrently - and at no point in time during the life of the `Mutex`.

So how could `T` contain an LLVM poison value, in a place where our thread could read it an base control flow on?

On the other hand, I checked in compiler explorer that a Mutex with `inner: core::mem::MaybeUninit<T>` generates the same optimized code for the example I gave above, as the variant with `inner: T`. So `MaybeUninit` may indeed the best combination, providing better code generation while still being very cautious.