That's like saying that &mut T is just static &UnsafeCell<T>, or that &T is just static *const T. Giving stronger static guarantees, better optimizations, better ergonomics, explicit intent documentation and more powerful features is a good reason to introduce new features.
&move T would allow safe pinning, dyn-safe moving methods in traits, passing by value arrays and vectors with a single interface and without using iterators, most use cases of Box in a #[no_std] environment, userspace Box, passing unsized objects by value, and even more complex features. The entire moveit crate would be reduced to a few safe functions.
I was talking about the moveit crate, which is far more complex, feature-rich, and requires way more than a single line of unsafe. Strictly speaking, it doesn't even deal with self-referential types, just non-moveable types in general, which makes it immediately out of scope for your crate.
Also it seems like you're overselling your crate, since it also contains more than a single line of unsafe. For starters, there is an unsafe trait Opaque and a macro opaque! which unsafely implements it. The lifetime-based transmute also looks very dodgy, and a good argument against the "easy to implement" claim.
Sadly macros require us to expose more than we want to.
It's one line of unsafe in the interface between the crate and the Rust language. Everything else is just plain safe Rust. Including the crate users.
Points of comparison are every other self-referential crate out there which hides the allocations, and moveit which looks to be... even more complex than self-referential crates, while also exposing the unsafety? And it also still hides the backing storage?
While at it, we're also working on a solution to the "need to use Option-wrapped references everywhere" problem.