We are circulating back to my first question, why the constructor has to be public.
Think about it some more. Suppose the default was that the constructor was private. Now, without specifying a constructor, no record could be instantiated at all, without the user declaring a constructor! That would be terrible. Part of the point here is that the require acquires a standard, sensible external API _without_ the user having to declare these elements. Users's get to say `record Foo(String s)`, and get everything they need to use the record.
If Java had factories, then we could quite sensibly decide the mandated API is a private ctor and a public factory. But it doesn't, so we can't.
OK, I suppose the next thing you are going to say is "Sigh, I guess the default (implicit) constructor has to be public, but if I _explicitly_ provide a constructor, I should be able to 'remove' it from the API." But, why do that for the constructor, and not for the accessors? In addition to it violating the "there's one, uniform, mandated API" principle, it would be yet another gratuitous sharp edge.
Or, maybe you're going to say "yes, the user should be able to 'edit' the API as they see fit; if they don't want an x() accessor, they can make it private." That's a valid alternate point in the design space, but that's not the design center we chose for records. There is a lot of value to the fact that a fully functional API (construction, deconstruction, access) can be mechanically derived from the record descriptor. Once you start letting the user tweak each aspect, we lose this benefit -- and for what?
Sure, we could opt for an approach where records are their own little world of special-case complexity. Which might be a valid alternate design philosophy -- but the reason we didn't go there is that the return-on-complexity just isn't there. In fact, one by one, we've been _removing_ gratuitous differences between records and classes, and each time we did, the design seems to have gotten better.
