In the proposal, you discuss about adding keywords like "non-final, unfinal, mutable", i.e. considering that there can be a different set of keywords for data class declaration which is different from the one we have on fields. In that spirit, we can have a flag like nullable, maybenull, etc to specify that the compiler will not generate a requireNonNull inside the principal constructor and that equals or hashCode do not need nullchecks.
Not really a fair comparison. The keywords suggested like "non-final" are not adding new concepts; they are merely making explicit something that was previously implicit. They are more akin to allowing the "package" keyword to describe the default accessibility of class fields, rather than a new feature. Non-nullability, on the other hand, is indeed a new feature. And, it is not a simple property of fields (well, it could be, but I suspect users would find that to an unsatisfying interpretation of "support for non-nullity.")
Ignoring that, what I think you're saying is "You don't need to do full-blown nullity propagation, you could simply have an 'annotation' that triggers a null check on data class constructors." And if that's what you're saying, I agree, we could do that. But I suspect the limitations of this would very quickly turn opinion negative. (Can't use it on non-data classes. Can't use it on locals. Using it on non-final fields starts to get messy fast -- do we have to do this on all field writes? Etc.)
