This is a very interesting question - one that no doubt will have a multitude of answers from a multitude of people with varying levels of understanding. Let's make one thing clear - the notion of 'newness' is itself
not intrinsic to requirements, since a client of an object/contract implementation has never cared about 'newness'. What they have cared about, in some circumstances, is the identity of a contract implementation - and specifically, when the contract exposes the ability to 'mutate'. Specifying "newness" (or equivalent) in a requirement specification is called a requirement defect (a more general term for excess of requirements). That is, since requirements have been exceeded, the specification contains a requirement defect.
There is a very subtle difference between "newness" and "contract implementation identity". Sidestepping that issue for a moment, I refer anyone to the ContractualJ API Specification which explicitly states: "All constructors are declared private, and throw java.lang.UnsupportedOperationException, unless they are implicit constructors of anonymous classes. Exposing construction details (as
Java constructor semantics implies) is not permitted."
This is because constructors (as we known them) implicitly exceed requirements, and the language (thankfully) provides a more appropriate (but still not optimal) alternative.
The definition of 'mutate' needs to be stated: "When invocation of one operation on the contract can be observed through invocation of some other operation". Here is an example:
interface I{void setX(int x); int getX();}
You will note that invocation of the setX operation can have an effect that is observed through the getX operation. Therefore, you would care about identity of contract implementation (implementation of interface I) since the contract exposes mutating operations - since of course, after you invoke setX, you wish to know the identity of the contract implementation through which you can observe a side effect.
This also leads to another interesting issue: the setX operation is not symbiotic with the getX operation - the relationship is unidirectional (symbiosis demands bidirectional relationship). That is, the setX operation is directly related to, and dependent on for its existence, the getX operation, but the getX operation can exist in a legitimate use case on its own (without the setX) operation. We often express this relationship using interface inheritance, but this has devstating consequences, albeit being the best known option within the language. A new language may consider offering a more appropriate expression of this requirement.
On this premise, which I have understated quite extensively (for now), it is quite clear that "cloning" or "copy constructors" really have no legitimate existence within a valid requirement specification More so, the identity of a contract implementation is what is paramount. If cloning and/or copy constructors are what does it for you, then so be it, however, I offer the possibility that a more appropriate alternative exists. The downfall being the mandate of a third party dependency which mandates some kind of expression of "newness". That is to say, you are forced to care about something you shouldn't by some dependency. I run into this issue myself quite regularly, and even within the Java language itself. It is important to acknowledge these dependent requirement defects if indeed that is what you have, so that you can make a fully informed decision about the pros and cons of your available options.
In summary, both Cloneable and/or copy constructors are equally (infinitely) invalid, however, you may be able to exceed and/or produce invalid requirements without clients ever knowing about it. The whole industry rides on this premise - from my perspective at least (I can't speak for the *entire* industry, but I'm waiting for a scrap of evidence to the contrary).
I hope this little rant helps - mainly, that you understand that the answer to your question is really quite non-trivial (despite the extreme simplifications that you will no doubt receive), and is probably best answered by Thinking for Yourself
as is any reality that is obscured by the popular belief system. Good luck mate.