Easier construction for records will come to Java. As with most Java features, it will come once it's been carefully considered, and done in a way that gives the most bang for the buck (e.g. we do want easier object construction, but if we add a feature for that, we'll try to get more than just easier object construction out of it).

> And don't get me started on array vs list vs collections none of which are compatible with each other.

This is not true. Lists are collections, and while arrays are different, Arrays.asList() gives you a list view of arrays.

> And hundreds of other QoL improvements that are begging to be implemented, and are not.

First of all, just in the past five years we got local variable type inference (var), switch expressions, records (with much more to come), sealed classes, and basic pattern matching (with much more to come), and string templates are around the corner. All of those are significant QoL improvements.

Second, every feature comes at the expense of all others -- both because of opportunity cost and overall language complexity budget -- and the question is one of priorities. Not everyone has the same priorities.

Finally, because Java is expected to remain extremely popular for at least a couple more decades, we must be very careful about adding features. While other languages are trying desperately to gain many developers right away, we're looking ahead to ensure that we'll be attractive to developers in ten and twenty years from now, and so must spend the complexity budget carefully.