My problem with the word “unsafe” is that many people seem to think unsafe code blocks necessarily have security issues. Hence the bullying of library authors even in cases where the authors did their homework.
Anything about the mechanics of the implementation is a second-order detail compared to that, as far as I’m concerned.
Also, I dislike the word "unsafe" since "unsafe code" is easily (mis)interpreted to mean "invalid/UB code", but "invalid/UB code" is officially called "unsound" rather than "unsafe". Unsafe blocks are used to call unsafe functions etc. (they pass information into unchecked operations via arguments), and unsafe trait impls are used by generic/etc. unsafe code like threading primitives (unsafe trait impls pass information into unchecked operations via return values or side effects).
unchecked would make a good keyword name for blocks calling unchecked operations, but I'm not so sure about using it for functions or traits.
For example, this is UB:
unsafe { std::hint::unreachable_unchecked() };
And this is an unsound code, that may not contain any UB if I call `unsound()` with `false`: fn unsound(trigger: bool) {
if trigger { unsafe { std::hint::unreachable_unchecked() }; }
}