You want one interface for the FigureKit's Path and one for the Path
that the DrawingKit draw_path function takes?

I'm not sure I can disagree more. :-) I wanted the clients to get a 
Path_var from the FigureKit, and a Very Dumb wrapper Graphic which takes 
the Path_var from the client and calls DrawingKit draw_path with it when 
traversed. Part of the reason is to keep only one true Path API around 
for consistency and clarity.

If you don't value that, then we can break it into two pieces, one of 
which is a secret between the FigureKit and the DrawingKit. Oh, and any 
other client-side Graphics who might care, but we can safely ignore them 
by saying "don't do that then" in the documentation.

Actually, your PathSegment in a struct makes a whole lot more sense when 
considered as part of approach. :-) One thing we should keep in mind is 
that some DrawingKits will have accelerated draw_rectangle 
implementations which wouldn't be accelerated in draw_path. The 
LibArtDrawingKit is currently such an example. We could work around this 
by allowing a new PathSegment of type Rectangle so that the backend 
could Do The Right Thing.

Stefan, if this seperation is what you intended, one Figure::Path and 
one Fresco::Path, then I'll happily use your Path internally and expose 
only my original API from Figure::Path. Does that satisfy both of our 
design requirements?