Most programmers have more experience with object-identity languages, as opposed to a value-identity language like Zig.
In languages like Python, a value which isn’t immutable is implicitly passed by pointer / reference, and if you want a copy, you have to do explicitly make a new object and fill it up. Which is the opposite of how things work in value-identity languages.
In any case, I’m glad @andrewrk linked to the pinned-attribute issue, because this is going to be a repeated stumbling block for using the new read/write interface until we gain the ability to specify that the location of a type in memory is an invariant property of that type instance, which cannot be moved somewhere else without annotating that the move is on purpose (casting, more or less).
I know some of us with Rust experience have, idk, call it Pin fatigue, but the underlying concept is admirably simple and it will be good for the language to gain it. In Rust, pinning connects to a bunch of gnarly concepts which Zig has declined to add to the type system; in my experience it’s the interaction of those things which makes Pin such a headache, not the fundamental idea of specifying that data must remain where it’s put in order to be useful.