wouldn't it make more sense to implement ICloneable semantically instead? Also I noticed that in every copy constructor the code is just copying the reference for properties, instead of making a copy of the object. That means that a change on myOriginal.PropA.PropAlpha = "foo" would also impact the copy myCopy.PropA.PropAlpha is now also valued at "foo". This could have tons of side effects. See how I implemented it for Kiota https://github.com/microsoft/kiota/blob/d19d14e06bc6fcadac91d208d2bf1c54c1a8918c/src/Kiota.Builder/CodeDOM/CodeMethod.cs#L160

Do you mind expounding on the side effects?
Also implementing ICloneable semantically as you've done in Kiota would require type-casting when one is trying to mutate the cloned object?

Seems to be related with #537. I hope ICloneable, no side effects and no hierarchy problems, is implemented for all models.

The API design that was approved for minimal APIs was to be able to use copy constructors. By having copy constructors it allows creating a new instance of the object and then using object initializers to set values. e.g.

app.MapGet("/foo", () => {})
.WithOpenApi(generatedOperation => new(generatedOperation) {
  OperationId = "MadeByMe"
});

It is not possible to do the same with ICloneable. Can we switch this to use copy constructors?

Also, it is not necessary to clone strings. Strings are immutable and so there is no harm in having the clone share a reference to the string. If one of the properties is updated, it will not affect the other.

sorry for the confusion, I didn't have the additional context on this one.

Thank you for the clarification. I'll revert the PR to the state where I had implemented the copy constructors.