However, it's true that there is still no consensus what exactly is allowed with unsafe and what's not. A parallel to this would be a confusion whether pointers of different types are allowed to alias in C – it's undefined behaviour, despite being counterintuitive to many.
But there's an ongoing effort to define and formalize the Rust memory model, which would provide an end to this debate. Recently, there has been also discussion that it should be not only defined, but also more intuitive than C's one, for instance. Undefined behaviour shouldn't be allowed to take you by surprise too easily.
Anything else about expressing unsafety of algorithms, or validations not expressible in Rust type system shouldn't be marked unsafe just because of it.
Then again I am just a vocal language geek and the Rust community should decided what is best.
So we're left with two options. The first is to say, despite the typesystem, a UTF-8 decoder for &str isn't permitted to do anything that would be invalid/undefined/wrong if done to an arbitrary &[u8]. (In other words, &str is merely a hint, and everyone must code defensively as if any &str could be an arbitrary byte string.) The second is to narrow "safe" down to "does not break typesystem invariants," even though the set of possible typesystem invariants is pretty large.
I think Rust actually has a good claim to being different from other languages here, given how much more of a typesystem it has, and given how much more it tries to do with newtype wrappers and zero-cost abstractions. The inability to use newtypes for optimization would be pretty unfortunate in a language that otherwise does so many excellent things with detailed typing. There are some languages where types are just hints (I think Objective-C basically works this way), but that's definitely not Rust's style.
It kind of is related though since there are APIs that do unsafe things based on this assumption, IIRC.
The type has some guarantees, and while the guarantees aren't related to memory safety, breaking them will cause memory safety issues.
At least in C there is a consensus about what works and what doesn't -- i.e. pointer aliasing is technically undefined behavior but the modern compilers let you get away with it. In Rust there doesn't even seem to be a consensus about how the compiler should work.
Careful, there has been much gnashing of teeth over the fact that higher optimization levels of gcc do very surprising things with "undefined" code.
In practice that consenus has little to no meaningful impact.
In Rust on the other hand you have people that deeply care about problems like this, demonstrated not just by what they say but what they do. I think you can therefore have a lot of confidence in them not just reaching consenus on this issue but creating meaningful solutions based on that consensus.
This is exactly the kind of situation Rust wants to avoid.
The name was chosen because it was the metaphor the author thought of; as a bonus, you've learned something about another culture. Tootsie pops (the most common lollipop in the United States) have a privileged place in American pop culture because of this commercial: https://www.youtube.com/watch?v=O6rHeD5x2tI