I’ve said this before (as recently as in the answer to your last post), but cramming everything in one giant vgPath is not a way to make things run faster. In fact, the opposite can easily happen.
To understand why, please refer to the spec in section “8.7.2 Stroking Paths”. In monolithic paths, that intersection must be detected and eliminated by the OpenVG driver. Chances are high, that this will involve at least a O( n log(n) ) operation on the number of segments [and perhaps even an O( n^2) operation]. This operation is complex (usually all intersection points of the widened geometry need to be found), and odds are high it will be done in software. Not all calls to vgDrawPath() are created equal (i.e. 50 calls @ 10ms each < 1 call @ 750 ms)! In general the length the vgDrawPath() call takes is directly proportional to the number of pixels on the screen you are changing times the complexity of the operation you are doing to them ( please note: (pixels_a+pixels_b)complexity_c == pixels_acomplexity_c + pixels_b*complexity_c ).
If you keep the size of paths sane, odds are it will run much faster than a single huge 5000 segment mega-path. That does not mean you need 1 path per segment, but it is probably best to stick to under 200 segments or so (give or take a couple hundred) per path.
Much more important than submitting stuff in one giant batch is to call vgAppendPathData() only once, and then call vgDrawPath() repeatedly without modifying the geometry. So, for example, if you’re animating, it’s thus better to have a separate path for each animation frame, then to be updating the same path each frame with new data.
So just use different paths for different colors. It’ll make you life easier, and I doubt it will have any great negative impact on rendering speed.