I've already revised the OP - allowing zero to & and &mut will never happen. The zeroable reference primitive is NOT replacing the non-zero reference; they coexist.

H4n_uL:

Before reading

This proposal SHALL NOT change:

• Semantics, layouts, and niche optimisations of &T, Option<&T>, and NonNull<T>
• Validity invariant of non-zero reference primitive - &T and &mut T (0x0 remains null for them)
• All existing safe and unsafe APIs that do not access 0x0
• ABIs

Anyway, your AnywherePtr<T> + field projection seems interesting and I think it naturally points toward making it a compiler-known primitive. Once you need lifetime tracking, borrow semantics, and field projection on a pointer type, it becomes difficult to express that purely as a library type without compiler support. At that point, promoting it to a new reference primitive seems like the more natural path.