immutability: can valuables be mutable?

I am a little confused. On this page, we can read this interesting conversation about whether valuables can be mutable or not:

– Phil Goodwin: it has been proposed that ValueObjects should be
immutable to avoid alias problems that would occur if
two objects contained references to a single mutable instance of a value
object. Remember that ValueObjects derive their identity from their
state. As a result, changing the state of a ValueObject is equivalent
to change your identity below your reference. Changing the
state of a ValueObject that is held by two different references
objects effectively change the identity of both objects
sustained even when the intention is generally to change just one. Doing
immutable valuables solve this problem by forcing the developer
to create a new object every time some aspect of ValueObject
state changes This is certainly a viable solution, but it is not the
Only one available.
Another solution to the same problem is
keep ValueObjects, not by reference, but by value. This is coming
naturally in a language like C ++ where the distinction between
Values ​​and references are explicit. If two objects have the same
ValueObject by value means that there are two separate instances of
the same state and that changing state of an instance is not
equivalent to changing the state of the other. This solution trades
the convenience of holding all objects by reference to
convenience of being able to change any aspect of a ValueObject
Been without having to create a whole new object to do it. It is
generally implemented by defining a copy constructor and a mapping
operator that copies the state of one ValueObject to another and
one or more comparison operators (== ,! =,>, <, >= and <=) that
Compare the state of one ValueObject with another. This strategy has the
happy side effect of allowing aliasing when desired simply by
keeping ValueObject-s by reference instead of by value.

– Michael Feathers: Phil, I think I see where you're going with this,
but I think the immutability of ValueObjects is really part of
its nature The old saw "is a date changed the same date or another
date? "illustrates the problem. Something like 12/12/98 is a pure value.
A variable can have that value, but the value itself cannot be
changed Imagine a class with a variable "numberOfWheels" You can have
value 4 sometimes. You can change the numberOfWheels value, but
you cannot change the value of 4. 4 is a value. For me, an object of value
It is something that represents pure value.

– Phil Goodwin: But you can change the value of a variable that has
has been set to 4. The value of 4 has not changed but has changed
The value of the variable. The key question is not whether the values
they themselves are immutable (we agree that they are) but if the
The containers for those values ​​must be immutable. What i say is
that if you spend the values ​​making copies of their
containerized representations for those representations then the
Containers do not have to be immutable. If, on the other hand, you pass
the values ​​around by copying references to those containers and then
Containers have to be immutable. The difference is that in the
first case, the containers contain the values ​​and in the second the
Containers are the values.

– Russell Gold: Seems to me you're confusing variables
(l values) and objects (r values). It is true that a variable can be
constant but that's not what we're talking about when we talk about a
ValueObject. There is nothing wrong with a variable having one
Immutable ValueObject and then another. But in that case, it's the
variable (container) that has changed, not the ValueObject.

Phil Goodwin: Actually, I think the confusion is not over with me.
It seems to me that people confuse references to an object with
The object itself. In Java, all objects are kept by reference so that the
The difference cannot really be exploited. In C ++, however, you can keep a
object by value. In that case, the variable is the object. I think
confusion can be between variables (l values), values ​​(r values)
and objects (any). A variable can be an object by value or a
reference to an object. ValueSemantics for objects by value are
preserved by copying values ​​between objects. ValueSemantics for
Objects by reference are preserved using a CopyOnWrite mechanism. I
He had always thought the story ended there. They are simply ValueObjects
objects that retain ValueSemantics or is there something else to

Who do you think is right, Phil Goodwin who supports that valuables can be mutable, or Michael Feathers and Russell Gold who support the opposite?