Even after merging #20414, both copy and (the identical) deepcopy have weird semantics in relation to the MIPVariables in a problems -- because a MIP does not have an API to gain access to its variables; and trying to use the old MIPVariables with the copy is questionable and definitely broken if one creates new components of this variable, see #15159, #19523. Same when there's no explicit MIPVariable and only the _default_mipvariable is used via the problem's __getitem__ method:

sage: sage: p = MixedIntegerLinearProgram()
sage: p[0]
x_0
sage: q = copy(p)
sage: q[0]
x_0
sage: q[1]
x_1
sage: sage: p.number_of_variables()
2
sage: sage: q.number_of_variables()
1

Here's a possible fix without having to change the whole design:

• a new MixedIntegerLinearProgram.copy method that takes a names keyword argument, enabling this operation:

sage: p.<x,y> = MixedIntegerLinearProgram()
sage: q.<newx,newy> = p.copy()

and the less magical syntax

sage: q, newx, newy = p.copy([x, y])

• copy and __copy__ (and __deepcopy__) should make a copy of _default_variable (this requires writing a __copy__ method for MIPVariable)
• if MixedIntegerLinearProgram.new_variable has been called, it should set a flag and then if __copy__ (or __deepcopy__) are called, it should display a warning (deprecation??) and refer the user to the new copy method.

In this ticket, we take care of the default MIP variable.
#20657 will take care of the variables created with new_variable.

CC: @dimpase @videlec @jdemeyer @nbruin @fchapoton

Component: numerical

Author: Matthias Koeppe

Branch/Commit: dff27e5

Reviewer: Dima Pasechnik

Issue created by migration from https://trac.sagemath.org/ticket/20461