ok, here is a quite different 'path'
data structure. It's all a bit rough, but it
should be enough to transmit the general idea:
A path is a sequence of 'segments', each of a 
specific type. Segments are then implemented
by means of (CORBA) unions, so their exact
substructure can depend on the type. That means
the data layout can be optimal for the given type.
No need to cary two control points per vertex if
this is going to be used as a polygon, etc...

Here you go:

struct QuadricCurve
{
  // whatever it takes...
};

struct BezierCurve
{
  unsigned long order;
  sequence<Vertex> controls;
};

struct NurbsCurve
{
  unsigned long order;
  sequence<Vertex> controls;
  sequence<double> weights;
  sequence<double> knots;
};

typedef sequence<Vertex> PolygonCurve;

enum PathSegmentType { polygon, quadric, bezier,
nurbs};
union PathSegment switch (PathSegmentType)
{
 case polygon: PolygonCurve polygon;
 case quadric: QuadricCurve quadric;
 case bezier: BezierCurve bezier;
 case nurbs: NurbsCurve nurbs;
};

struct Path
{
  sequence<PathSegment> segments;
  boolean closed;
}

The 'Path' type itself in this example is a
struct, but it could well be an interface if
that's *really* necessary. If it is an interface,
we can endow it with a convenient interface to add
segments intuitively, if it's a struct we have to
provide convenience *functions* to all sides
(server and client runtimes).

Also, using an interface would provide us with the
means to control modifiability, and thus cacheability.

Food for thought...