@jeff and @marlin this was written to keep you two updated, but figured I may as well post to discourse in case anyone else cares.
I just checked in code for drawing clipping coordinate curves using a rewrite of the curve buffer classes in the WIP.
http://mcneel.myjetbrains.com/youtrack/issue/RH-30336
I wrote this a couple weeks ago, but didn’t have the nerve to check it in until after I got back from vacation and a WIP went out 
The new buffer was written to keep vertex and color information in a structure that allows us to make a single call to glMultiDrawArrays instead of a ton of glColor, glVertex calls in a for loop.
The OpenGL display engine now has a driver level variable that we use to determine how to draw geometry.
For a driver level of OpenGL 2.1 or higher:
The buffer is flushed with a single call to glMultiDrawArrays. Z-Biasing of the curves is done with a basic vertex shader.
For a driver level of less than OpenGL 1.2
The only time I think we will run into this level is when the Microsoft software OpenGL driver is being used. glMultiDrawArrays is not available in OGL1.2 so the buffer is cleared using the old technique that we used in Rhino 5. This involves setting up a for loop with a bunch of glColor and glVertex calls. The z-biasing is also calulated inside of this for loop.
What does this mean?
I ran gDEBugger on a frame with a wireframe viewport displaying a brep sphere. With this new code in place, there is not a single call to glBegin, glEnd, or glVertex while rotating the viewport. The number of calls into OpenGL is also dramatically reduced since a single glMultiDrawArrays call replaces tons of glVertex, glColor calls. I’m going to assume that this will be much faster with some OpenGL drivers and at worst the same speed as before with other OpenGL drivers.
This rewrite was pretty significant, so we need to keep our eyes open for any strange curve drawing issues over the next few WIPs. This code was just checked in, so the public will see this next week.