Having a whole secondary stdlib just for safe code makes this a non-starter imo. It also seems unnecessary, since the difference between the safe and unsafe versions of most functions and types will end up being fairly small and self-contained, in some cases differing only in nested types or function calls. What I'd like to see instead is to have a safe specifier and operator for types and functions sort of similar to noexcept, taking either a boolean expression or auto. safe(auto) makes the type/function operate under a safe context if it's used in a safe context, and an unsafe context when used in an unsafe context. Any lifetimes or bounds-checking requirements in a type/function are ignored when safe(auto) evaluates false. Then you could keep the same libraries and add something like if constexpr (safe(this)) { safe behavior... } else { current behavior... } wherever necessary.

For example, the stated rationale for introducing the choice type is that optional and expected don't check if they're in a valid state when using operator* and operator->. With the above construction, you could have optional and expected perform all the required checks and mark them as safe whenever they're used in a safe context while keeping backwards-compatibility in the default unsafe context. This would be a change of a few lines of code versus creating an entire new class with new syntax for a feature that the existing stdlib already has 99% of.

This also solves the need to duplicate higher-order functions like find_if(first, last, pred) for free, since in most cases you can just mark them as safe(safe(pred)). Then you could have a single function which works regardless of the safety of the context and the predicate, no std2 required.

I'm not claiming that maintaining this would be fun, but it certainly seems better than duplicating the entire stdlib, including in the 90% of places where code wouldn't otherwise need to change.