It is dangerous to let `tr` go optional now that we are using this general `slice_times` concept. I see that if the user declares an irregular slice acquisition and uses a default `tr` value, then the method can do really weird stuff. My worry is that some users might think they don't need to provide `tr` if they have already provided `slice_times`, which seems to make sense at first sight, but is wrong in general: if the acquisition is irregular, the algorithm just cannot guess `tr` from `slice_times`. 

Following your comments, I am changing the backward compatibility policy here: any passing of obsolete keyword arguments (`slice_order`, `tr_slices`, ...) will raise an error. Likewise, if the first argument is a sequence (probably meaning `slice_order`), an error is raised. This might be painful now for some users but safer in the long run, I hope.