Think of raising an orbit like moving an item from one side of your desk to the other.
You have to put energy into doing it, but the end result is just as much in balance with gravity as the starting point. So if you want it back where it was, you need to spent the same amount of energy to move it in exactly the same way in the opposite direction.
With dynamically sized types like `str`, Rust allows to separate "what kind of pointer + metadata is this" from "what kind of data does it point at". So, for example, you can have the types `str`, `[T]` or `Path`, and can have them behind the pointer types `&T`, `Box<T>` or `Arc<T>`.
If Rust had defined a special struct `Str` for `&str`, then it would have to define special structs for all the combinations possible: Str, ArcSlice, BoxPath, etc.
The github discussion thread where that originates from also contain the language designers optimistically discussing how in the worst case `Pin` just has to be hardcoded to exclude these optimizations. Which wouldn't make it the first type in the std lib that works similary (see interior mutability and UnsafeCell), so I personally intepret that as "unlikely to be an issue".
Fully agree with that, and Rust makes that very easy still. Its 5-10 lines to spawn multiple threads that communicate with each other either via shared state or message passing, and I solve most paralleism problems that way to this day in Rust. :D
The flip will be less extreme in later designs because they will have better/larger RCS control thrusters to rotate it without involving the main engines.
Also the center of rotation can be controlled to be inside the passenger section. Add some seats that can automatically tilt 90 degrees and the forces might be barely noticable.
Note that that is passing by value, so its moving/copying ownership. Its like having a immutable integer variable and copying it to a different mutable variable.