It's all linear, always. Two things about pre-ringing. First of all there's the psychoacoustic phenomenon of pre-masking (aka backward masking) in which a quiet sound won't be heard even if it precedes a louder sound by a few ms. The limit ranges from 5 ms to 20 ms according to papers on the subject, and I seem to recall that lower frequencies have a longer pre-masking effect (not sure about that one) because your perceptual temporal resolution goes down with frequency (see this paper for instance http://kurser.iha.dk/eit/eaku/litt/Psychoacoustics.pdf
And then there's how you design your filter. At a resolution of 1.0 (in SplineEQ) the pre-peak part will be a maximum of 11.6 ms, so even a brickwall filter won't pre-ring more than 11.6 ms, which might be covered by psychoacoustic pre-masking, and if it's not then you can definitely lower the resolution to 0.43 which will give you 5 ms of pre-ringing tops, no way you can hear that. And for how you design it, if you have sharp changes then it's going to ring, if you keep it smooth it's not going to ring.
I'll try to offer some phase variety, the way I see it I should have a knob with on one end linear-phase and on the other end minimum phase, and in between you'd have a smooth rolloff between the two with the frequency at which that transition is centred moving along so basically it would swipe from one to the other, the benefit of having that would be so you could have linear-phase high frequencies and minimum-phase lows, does that sound good? I'm not sure about having it like LP10 and set the phase response for each band, mostly that in SplineEQ there's no such thing as a band, they're control points, there's just no traditional concept of bands (even though the interface calls them that) which usually kinda act like individual filters that are just summed up together.
Concerning the On-Off thing, I can do it, but there's one problem, you could turn a control point off, and then turn it back on, but if you ever select another point then your disabled point is gone. Also because they're not actual bands I'm not sure how much sense it would make to disable them. So, practically speaking I'm just not sure what good that would be. It makes sense in any other EQ that uses bands as individual filters that don't interact with the rest except by summation, but in SplineEQ I don't think it really works as well. By the way if your host offers you access to the plugins parameters in the form of a crapload of sliders you can already turn bands on and off with the first parameter of each band which is just an off/on thing.
Oh and as for the delay I can actually improve that a bit. When I first made SplineEQ I was too concerned that the convolution algorithm would take too much CPU for anyone's taste so I made a short list of FFT sizes that ran fast for their size, which means there are big gaps, as much as 25%, between two possible FFT sizes, which makes reducing the latency harder. With a more fine grained list of FFT sizes we could shave off a few extra milliseconds of latency (up to about 10 ms for about the normal resolution, more for high resolutions) to reduce the internal buffer size (though it could not be reduced to lower than your hosts audio buffer size).
Anyway, I totally agree that SplineEQ should have a minimum phase mode as it's a shame that an EQ with such a workflow and interface would be limited to linear phase. However because it uses convolution it still would have a bit of latency as unlike IIR filters or time convolution (which is prohibitively slow) which can work on individual samples the convolution algorithm has to gather a certain amount of samples (the "buffer" part of the latency) into a buffer which only then it can convolve.
By the way there's something about the way I calculate and report the latency that doesn't make sense to me. Right now it's half the size of the kernel + the size of my internal buffer, but what if the internal buffer was the same size as the host's buffer (provided a constant buffer size), then wouldn't the buffer just not count as part of the latency? I should test again if SplineEQ nulls properly.