One of zerocopy's target user bases comprises users who are especially concerned with reliability, safety, soundness, trust, etc. Quoting from #98:

On the other end of the spectrum, many of our users come from domains which generally have a high bar for correctness - kernels, hypervisors, cryptography, security hardware, etc. These users are extremely wary of taking external dependencies, and only take dependencies when they absolutely need to or when they have a high degree of trust in an external software artifact.

In order to reach users in this camp, we must:

• Hold ourselves to a high standard for correctness and soundness
• Articulate this standard concisely but in sufficient technical detail that a user in this camp can come away from our docs comfortable with taking a dependency on zerocopy

In a comment on that issue, @briansmith confirmed that this characterization is accurate, at least for him and for the crate he maintains, ring (emphasis added):

These users are extremely wary of taking external dependencies, and only take dependencies when they absolutely need to or when they have a high degree of trust in an external software artifact.

@joshlf made a PR for ring that shows how zerocopy benefits ring by reducing its unsafe code that's duplicative of zerocopy. And zerocopy has a higher bar for documenting and validating its correctness than my more informal approach in my own code. OTOH zerocopy is so large that I pretty much just have to take it on faith that y'all care so much about getting all the details right that I don't need to bother looking through it, because I can't (don't have time).

This relationship - in which the user trusts that the crate was authored with a high emphasis on quality but does not audit the code themselves - is inevitable for most projects. It's the relationship that even the largest institutions have with projects like the Rust compiler and standard library. We can do our best to make our code readable and easy to understand, but at the end of the day, most users will be choosing between either a) trusting that we've done the work or, b) not using zerocopy. For most users, there's no c) audit the code.

For that reason, we should double down on what's described in #98: document our approach to soundness so that users who have a high bar for trust feel comfortable that zerocopy is developed to a quality standard that satisfies their needs.