I did try to make iter_segments work first. But I found that here (and #16859, and upcoming PR on center of mass), I kept repeating this logic across each function I wrote so that I could get all the control points of each curve, so I went ahead and added this generator.

A problem is that naively you'd thing the difference between iter_segments and iter_curves is that one returns segments and the other returns curves, but actually it's something completely different: one excludes the start point of each segment/curve and the other includes it. So should this instead be a kwarg to iter_segments, e.g. include_starts?

I'm happy to make this a private helper method that is called by iter_segments when the parameter include_starts is passed, but I worry about bloating iter_segments with a bunch of options.

Especially because it's really obnoxious that .iter_segments() returns a flattened sequence of coordinate pairs, so in order to create the desired API (more importantly to not doom anyone using this code in the future to a lifetime of reshape calls), I'd have to add another parameter as well flattened=False which determines whether to flatten the (naturally (N,2)-shaped) array of control points before returning it.

Oh, and currently, .iter_segments() returns a vertex that we're supposed to be ignoring (CLOSEPOLY) instead of correctly returning the first vertex of that stroke.

This is almost certainly a bug, but would probably want its own PR.

Adding the CLOSEPOLY bugfix, include_starts and flatten_vertices to iter_segments instead of just making a separate iter_curves makes the code significantly noisier, but if that's not as big of a priority as minimizing new API surface, I'm happy to do that.

Pushed up a new version where the generator yields BezierSegments and is named iter_bezier. I think this solves the problem that you (correctly) pointed out of the name .iter_curves not being intuitive, along with preventing me from having to make multiple, significant modifications to iter_segments.