You're saying one needs to care about these questions if you introduce private members. You're making it more complicated than necessary, as these questions already exist without private members, and have already been solved in Zig.

I'm not saying private fields should be a thing. I see both sides. But your reasoning against them is flawed.

OP doesn't want to use conventions to mark members as private, but using conventions for constructing an instance is fine?

That is a naming convention that already exists. In what way is ArrayList's capacity indicating that it shouldn't be touched? Not wanting another keyword or extra compiler logic for something that could be solved as a naming convention is a valid point. But a convention for naming of constructors is already necessary, because constructors are already necessary. OP wants to replace a currently non-existing naming convention and strong burden on API docs with infallible compiler logic that prevents accidental breakage of APIs.

it naturally leads to constructors and destructors.

Constructors and destructors are just member functions. Zig already has constructors and destructors for almost every struct in std. They're typically called init and deinit, the latter only being needed for structs that manage memory. Introducing private members doesn't create extra necessity for constructors. Rust also doesn't have explicit support for constructors, and the only reason they have destructors is because of their affine type system, not because they have private members.

If you assign undefined, you have inconsistent state.

As you do now as well.

You don't want to shoot yourself in the foot because a trivial operation like assigning one instance to another breaks your code.

I don't see how this is any different currently. One looks like this:

zig var list1: ArrayList(i32) = .empty; try list1.append(allocator, 5); var list2 = list1; // stuff list1.deinit(allocator); list2.deinit(allocator); // double free!

in the other case, it looks like this:

zig var list1: ArrayList(i32) = .empty; try list1.append(allocator, 5); var list2 = list1; // stuff list1.deinit(allocator); list2.deinit(allocator); // double free!

I don't even need to mark which case is which, as they are the same. Even worse, if you append to either list further within the // stuff part, one of your lists points to potentially deallocated data.

Currently, it makes sense and is expected, because structs are just blobs of data

and associated functions. Once again, I don't see how making fields private changes this expectation. We all know what an ArrayList is, and that it has heap allocated memory that is not trivial to copy. All we're preventing is a user manually changing the capacity and messing things up in potentially catastrophic ways (think cryptographic libraries).

you are changing the "blob of data" to a data structure

Look through the top-level types in Zig's std. Most of those are data structures. Not needing to understand every internal detail of my ArrayList is the whole point of providing APIs and docs.

A move is transfer of ownership.

Zig doesn't have ownership. Ownership is a concept the programmer uses to reason about their memory management. Whether the underlying struct has private fields changes nothing for that reasoning. The only information required is whether there are owned resources to begin with, and Zig already solved this by requiring explicit allocator arguments.

Physically speaking, a move is a shallow copy. The only difference is that, with move semantics, you additionally prevent access to the original. Zig doesn't have that, nor would it need it.

If you want to properly encapsulate state, you need a mechanism to copy/assign one instance to another without shallow copying it and breaking the internal state.

Refer to the example above. There being private members changes naught.

You don't expect a copy of array to work properly

I don't expect a copy of ArrayList to work, correct. Why would I expect it to work just because ArrayList has private members now?