I am concerned about deprecating a path code given how far down the stack this is.

Would it be simpler to replace the STOP with MOVETO in the concatenated codes?

Notionally 👍 to this change, concerned about deprecating STOP, holding off on approving given there are 3 proposed implementations ;)

this is still not deprecating STOP, just changing the behavior of make_compound_path.

3 proposed implementations

You mean#16822,#16812, and#14199? It may not seem like it due to the large overlap in conversation, but these are actually totally independent, incremental improvements to thepath/bezier interface :)

I will also point out here for the record that the "truly correct" behavior is something like

for path in args:    first_stop = next((i for i, c in np.ndenumerate(path.codes) if c == cls.STOP), None)    num_codes = len(path.codes) if first_stop is None else first_stop    codes[i:i + num_codes] = path.codes[:first_stop]    i += len(path.vertices)

but making this solution actually work adds a disproportionate amount of code complexity for a corner case (concatenating multiple paths with internal STOPs) that it's not clear we need to support (whereas concatenating a bunch of paths that correctly end in stop should surely work correctly).

Sorry for force-push. Accidentally pull'd in from master, had to rebase to trigger CI to finish running.

Force-pushing to your own PR branch is perfectly fine.

Thanks@brunobeltran!