Note that we may want to deprecate the STOP code, which is documented as "not required and ignored" but actually causes the rest of the path to be dropped silently; it gets appended by cleaned() and caused an earlier version of this PR to break (because the STOP would then cause the rest of the concatenated path to be dropped).

This sounds like a dangerous change of semantics when using the proposed alternatives.

The thing with STOP would be a separate PR anyways, I'm just noting it here because I realized its nonobvious semantics in this PR.

This needs a rebase and it is not immediately clear that not calling make_path_regular at https://github.com/matplotlib/matplotlib/pull/14199/files#diff-d6593efaf6f4a6b9fb34f84bfa9964b5L3219 is ok (I think it just lets p.codes is None pass through?) so pushing to 3.3

rebased
did you mean https://github.com/matplotlib/matplotlib/pull/14199/files#diff-d6593efaf6f4a6b9fb34f84bfa9964b5L3126? (your link doesn't point to an use of make_path_regular) yes, I know just let path=None pass through as such instead of expanding it to its synonym [moveto, lineto, lineto, ..., lineto].

A couple thoughts

1. Removing make_path_regular at patches.py:3190 is safe ONLY because the only place the arrow transmuters are used is get_path_in_displaycoord, which is only called by draw, which immediately concatenates its outputs.
2. Concatenation makes this safe only because the logic of make_path_regular is already duplicated in .Path.make_compound_path (see path.py:338 in Bezier/Path API Cleanup: fix circular import issue #16812 ).

Had I been more confident that rocking the waters with my own opinions on naming was okay, I would have proposed renaming make_path_regular to .Path.ensure_codes in #16812 , since this states more clearly what the function is really doing. In particular, you want to use make_path_regular whenever you want to make sure there are codes present (for example, this is important in .Path.make_compound_path, because without the explicit MOVETO at the start of each Path that is passed in, the compound path will not correctly be made up of multiple strokes).

My opinion is that the proposed replacement (.Path.cleaned(remove_nan=False)) does not accomplish the same goal as the deprecated function. However, if @anntzer is confident that concatenation is the only use case where you'd want to ensure codes exist, then I can rebase #16812 on top of this PR).

I clarified the deprecation note for make_path_regular to note that one may want to remove the final STOP.
I can't be confident that concatenation is the only use case, but it's certainly the only use case in the library right now. Do you have other use cases in mind?

I can't be confident that concatenation is the only use case, but it's certainly the only use case in the library right now. Do you have other use cases in mind?

Fair, I should have phrased this better. What I meant was something like, "as long as you guys agree that losing this functionality would hurt the users by taking away some use case I haven't thought of".

None of the use cases I was thinking of involve less than one stroke, it makes sense to make_compound_path first anyway.

In related news, since you've also noticed this STOP issue and are recommending usage of make_compound_path, I've always wondered....shouldn't make_compound_path do something like (at the end of the current function)

last_vert, last_code = vertices[-1], codes[-1]
vertices = vertices[codes != self.STOP]
codes = codes[codes != self.STOP]
if last_code == self.STOP:
    vertices = np.append(vertices, last_vert)
    codes = np.append(codes, last_code)

to prevent internal STOP codes after concatenating the paths?

I think we should just deprecate STOPs, unless there's a good reason to keep them (which I can't think of...).

I agree that STOP should be deprecated....but that seems out of scope of this PR, and until such day as it's actually done, it seems like make_compound_path should be made to do the correct thing.

Do you want to PR that?

Sure!