Yep, during discussions we decided to defer the ~Escapable generalization of unsafeBitCast, based on @fclout's objection and our general inability to precisely reason about lifetimes in these API proposals.
I'm already quite alarmed about finding myself having to introduce the idea of immortal nil values and (implicit and explicit) enum wrapping/unwrapping semantics, without stable syntax or an accepted spec for such things. unsafeBitCast and generalized pointer types would conjure borrowing dependencies out of thin air; I don't think it would be a good idea to introduce such things this manner.