This surprised me when it was first raised. But some of the feedback I've received makes me thing that it's a widely held view. The best answer is to consider the cases in the section Tutorials and Motivating Examples.

I couldn't figure out how to use it from the documentation.

I used "safe" in large part this is what has been used by other similar libraries. Maybe a better word might have been "correct" but that would raise similar concerns. I'm not inclined to change this. I've tried to make it clear in the documentation what the problem that the library addressed is

Actually, I believe that this can/should be applied to any type T which satisfies the type requirement "Numeric" type as defined in the documentation. So there should be specializations safe<float> et. al. and eventually safe<fixed_decimal> etc. But the current version of the library only addresses integer types. Hopefully the library will evolve to match the promise implied by it's name.

By whom? Is leaving code which can produce incorrect results better? Note that the documentation contains references to various sources which recommend exactly this approach to mitigate the problems created by this C/C++ behavior. See [Seacord], Software Engineering Institute - Carnegie Mellon University

As far as is known as of this writing, the library does not presume that the underlying hardware is two's compliment. However, this has yet to be verified in a rigorous way.

safe<T> behaves like a "number" just as int does. It has max, min, etc Any code which uses numeric limits to test a type T should works with safe<T>. safe<T> is a drop-in replacement for T so it has to implement all the operations.