That being said, I don't oppose the occasional judicious use of unsafe. If 99% of your code is verified, it's not 100%, but that's still a massive improvement over a C++ codebase.
The std APIs look like this:
struct Box<T, A: Allocator = Global>
Not quite. For the most general case, you probably want allocator to be a proper parameter instead of a type parameter. For example, suppose you have a green thread that you want to have its own isolated heap. Then you can't assume that any given allocator is a singleton in its type; The struct itself must somehow be able to find to its "owner" on release. In the green thread case you can't "just use threadlocal" because a green thread might not be sticky to an os thread.
It creates a strong incentive to only write safe Rust, which is great for the vast majority of people.
That's a pretty tricky thing to get right, and with the consequence for getting it wrong being UB, at least a little fear is warranted.
This is like applications adding artificial delay to operations so users aren't surprised they complete so quickly.
User understanding is more important than definitional correctness.
e.g. "mm256_shuffle_epi8" on X64+AVX2, ARM64+NEON and plain ARM: https://rust.godbolt.org/z/7rjKE93Kn
It currently only works with constant shuffle masks but dynamic shuffles are on the to-do list.
If it's to be portable it needs an extra instruction on one platform or the other because tbl and vpshufb do different things :(