I think the major issue is that it requires consistent IDs between frames in order to determine a correspondence between the particles. My understanding is that most people don’t use IDs so this interpolation mode simply won’t work.
I’ll add the request to our list and see if I can get it into an upcoming beta.
Why three extra frames more? You only need the Position and Velocity of the two bracketing frames for interpolation. . .
I meant that to get a particle position at frame T where floor(T) < T < (floor(T) + 1) you can do cubic interpolation with the Position and Velocity of the particle from frame floor(T) and (floor(T) + 1). Only two frames of the particles need to be in memory at any given time, unless we cache the bracketing frame data for quicker interpolation. If its cached then its the sample at T, floor(T) and floor(T)+1 in memory at the same time making the 3x memory increase you mentioned.
You could certainly do that as well. It seems less user friendly to me but equally valid.
Of course, with two positions and two velocities you can describe many more interpolating paths than with four positions. In practice it probably doesn’t matter though.