I think we ignore the point entirely forCLOSEPOLY, but what happens for something like?

p=Path(    [[0,0], [np.nan,np.nan]],    [1,79])

what happens for something like?

p=Path(    [[0,0], [np.nan,np.nan]],    [1,79])

Great question. It leaves it as-is. (Same as previous behavior).

>>>p.cleaned(remove_nans=True)Path(array([[0.,0.],       [nan,nan],       [0.,0.]]),array([1,79,0],dtype=uint8))

I think this makes sense because

1. We document that the vertex attached to theCLOSEPOLY command is ignored, and
2. We were already leavingallCLOSEPOLY's in before, including theseNaN ones

So this PR only changes the behavior when leaving aCLOSEPOLY in would result in an ill-definedPath.

I'm aware that this doesn't play well withPathSimplifier:

>>>p.cleaned(remove_nans=True,simplify=True)Path(array([[0.,0.],       [nan,nan],       [nan,nan],       [0.,0.]]),array([1,2,2,0],dtype=uint8))

but this is also existing behavior, and I haven't taken the time to grok the fullPathSimplifer algorithm yet to know whether or not it's easy to do even better.

Per the call, added tests that check the "optimized" code path (i.e. emptycodes array) and explicitly added the breaking example from#17868 as a test case.