I think there's an argument to be made for making the memberwise init public if all of the members are public, but not if only the struct is. Doing the latter would make it very easy to accidentally expose an unintentional init to downstream users, and one that changes when members are changed (i.e. one could only modify private code, and still stop downstream code from compiling).

Something that might handle both cases is being able to opt in to the compiler filling in the initializer body if the signature is right, e.g. C++-style public init(x: Int, y: Int) = default or something. This means that any (incompatible) changes to the struct's members will stop the defaulted initializer from compiling, alerting the programmer that they may be breaking downstream code.

Right. This isn't just a bug; it was a deliberate design decision, based on the principle that exposing API across a library boundary should always be explicit.

It's on swift-evolution to come up with a solution and proposal for this.