> Under the current regime this is not a breaking change because the authors do not intend `Point` to be serializable and do not want its consumers to serialize

> Under the current regime this is not a breaking change because the authors do not intend `Point` to be serializable and do not want its consumers to serialize it directly. Does your example not show a breaking change? With the old version, all fields are public, so users can construct Point values themselves, and fully deconstruct them with pattern matching. With the new version, the struct has a private field, so users cannot construct Point values directly. (Also, it has an extra lifetime parameter which users must specify!) That is to say, the authors do not intend to allow access to private fields (they say that repeatedly), so something that wouldn't ordinarily be a breaking change would not become a breaking change in the presence of this feature. Any additional behavior defined by consumers must be built on top of the provider's contract. In this case, either the additional serialization behavior would have to require all fields to be public, or it would have to ignore any private fields. And additional deserialization behavior would similarly have to either require that all fields are public or only allow filling values into existing structs.