I think that this solution is solving the problem in too unusual and
narrow of a way to justify making such core language changes.

Making a getter is already a viable solution to this problem. Also
keep in mind that getters aren't just there to prevent mutation,
they're also there to obscure layout. For example, you can internally
store a std::string but return a std::string_view, which gives your
class the freedom to store a C string or std::string_view as well, if
need be. Or similarly, you can store an unsigned char but return
std::size_t in a getter.

Furthermore, getters can prevent the user from taking the address of
the data members, which also gives you flexibility to change the
layout in the future. If someone is able to do &foo.value and expects
this to be an int*, you definitely cannot change the class layout
later without breaking code.

If you're going to approach this problem of getter/setter boilerplate,
it should probably be done through properties. Last proposal that
addressed those was
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf.
Personally, I don't think that properties are a good fit for C++
though, so there's really nothing that can be done here.