Linear -> exponential sounds great (although the nerd in me would love exp f(x) = x^x however useless it would be (disregard this)).
I think I initially assumed the easing would bunch up at where the time was in not set to linear. For instance that it would bunch up at .3 if easing were sat to .3 (VuoCurveEasing_Middle = 0.5), but both makes sense though.
This is where it gets out of hand, but perhaps a 3x2 matrix of options for the in and out easing could work?
This way, if both are set to in, the whole duration is calculated with an in-easing. In-linear gives in-easing until the center duration then linear the rest of the way. In-out gives in-out, and out-in gives middle easing and so on. In theory this could be hidden from stuff like the curve node while providing the same function as it currently has through the Vuo_curve function while giving a few extra options for other nodes. I assume that is on a different level of nodes to re-code if implemented though (unless it gets its own call at the bottom of the if-nest in VuoCurve.c; VuoCurveEasing_damnUnappeasableUsers(...)).
Signal drift, try adjusting the overscan to wrangle it in place for some time (it will still drift after some time though). Most likely something in the chain thinks you're running everything at 30fps when you run it at 29.97 (or the other mismatches). Over the 10 - 20 seconds that .03 leftover adds onto itself, and the box/driver/something don't know what to do when it gets info from the middle of the frame where it expects the beginning, and probably tries to auto adjust to the signal. You shouldn't run them at different framerates though, and it is far from reccommended. Putting a decent scaler in between can also solve this issue.
Can you check if the 30fps camera has a NTSC mode? Or if the PTZ can be run in PAL mode? Which camera models is it? If they both have 24/25fps modes that might also solve it.