Or maybe instead of leaving them as properties, they are rewritten as a helper get_allsegs_allkinds()? Again appreciate that some folks will want to access this directly from contourpy, but making this available doesn't seem too crufty to me.

Perhaps more general would be to have a Path().split() method (name up to bikeshedding) that takes a compound path (i.e. possibly with internal MOVETOs) and splits it in paths without internal MOVETOs? (i.e. the opposite of Path.make_compound_path)
Then the requested functionality would be something like [(subpath.vertices, subpath.codes) for path in contour.get_paths() for subpath in path.split()].

That seems reasonable, if an implementation detail. The above is still a mouthful for most people.

I'm a bit curious, though about why MOVETOs are a problem for you. After all, if you already handle allkinds, that means you already handle CLOSEPOLYs and need to differentiate between open and closed polygons, which seems already more complex than splitting at MOVETOs?

For my application, I didn't need to know if the polygon was closed or not. I was making KML files of the contours (for using in Google Earth) and I just needed the paths. But I needed each path segment on its own so I needed lists of contiguous segments.

Could I figure it out from the Path API? Probably. But it's understandably frustrating when CountourSet is documented to ingests allsegs in exactly the format I want, that it looses that information and I need to parse it out from the Path API.

... or put another way; I don't think 99.9% of our users know the Path API, and I don't think they should need to learn it for this application.

I don't feel overly strongly about this; we could just restore the old allsegs/allkinds properties (and fix them to match the old format, as you note in #26863 (comment), and mark them clearly as "exposed for practicality" so that they don't get removed in a future cleanup).