FWIW, I have a similar issue where a Rust lib was written that exposes a Rust interface to an FFI backed by a C IPC lib whereby the messages the C lib delivers aren't "stable" - the underlying buffer can be mutated. The intended usage protocol is you read out all the data from the buffer into locals (where the locals are all Copy types in Rust terms), and then call an API that indicates whether you raced with an update; if you raced, you're supposed to discard (and not look at) the values read into the locals and repeat the reads. So it's sort of like a CAS loop where you keep going until you get a stable set of reads.
While thinking about the proper Rust API to expose, we punted on exposing a &[u8] to the callers precisely for the reason that it's a lie as far as rustc is concerned. Still need to come back to this topic (left just the FFI bindings for now). This is essentially the same thing as the mmap problem discussed here.