Thanks for the PR! Indeed, when I wrote PR #3760, I missed the case where vmobject was the same Mobject as self (which wasn't an issue before my PR, because .get_cubic_bezier_tuples() returned a copy of the points). Thanks for catching this!

However, I think that your first approach was better:

Initially (in my first commit), I addressed this issue by modifying pointwise_become_partial so that it creates a copy of vmobject.points if vmobject is self, avoiding in-place modification of vmobject.points when self.points is set to np.empty(...). Making a copy is essential because self.points and vmobject.points are used together after self.points is set to np.empty(...).

because of two reasons:

• Mainly, it is a more general fix which addresses the root cause of the problem: I missed to account for when vmobject is self, which seems to be a pretty common case (to make a Mobject become a part of itself). Many other methods use pointwise_become_partial() and we have to account for the case where the template VMobject may also be the transformed VMobject.

• The first approach involves copying only the NumPy array of points (and only in the case where vmobject is actually self), whereas the current approach involves copying the whole VMobject (including points, colors and others), which is more expensive. Although Line._account_for_buff() is a method which is called once and thus it doesn't really matter, it could matter if we implemented this in other methods which involve for loops.

So, could you please use the first approach for this PR? Thanks in advance!

EDIT: Plus, to prevent things like this from breaking again, can you please add some tests as well? At least one for the general case where vmobject is self, and maybe a check that points are calculated correctly for Line when passing both buff and path_arc.

LGTM! Thanks for the changes!