Yes, but I think you missed the point of the parent comment.
> enabling developers to easily assign their own allocators
Through a combination of Zig's convention to pass around allocators instead of using a global allocator, the allocator interface's ability to return errors, and the Zig language forcing you to handle all errors (unless you explicitly discard them), a lot of Zig code is written with allocation failure in mind.
This means that you can seamlessly pass a custom allocator, say a bump allocator backed by a fixed buffer, to a function in some third-party library and still handle the case where the buffer runs out of space.
> so they would be avoided if we had non-movable/non-copyable types.
There is a proposal for this that was accepted a while ago[0]. However, the devs have been focused on the self-hosted compiler recently, so they're behind on actually implementing accepted proposals.
Again .. wow! Buy a pen at a store and it comes with a usage agreement that you may not write anything against <insert-party-name> using the pen! Not surprising that they removed the term as it would be overreach or something.
> this would require that unions can work on the 'bit level' in packed structs
Just as Zig has packed structs, it also has packed unions. So that part shouldn't be an issue.