train~ @resetmode 1

It seems that the resetmode argument of the train~ object doesn't work as documented:

When resetmode is set to 1, train~ will defer an interval change. If the interval is 2000 and you change it 400, train~ will wait until it completes the current cycle to change the interval to 400. When resetmode is set to 0 (the default), the interval is changed immediately.

To me it seems that the behavior of train~ is the same with resetmode 0 or 1: The interval change is always deferred to the next cycle. Even when I send a new interval value to the first inlet and then a bang, the beginning of the cycle is reset to the instance of the bang but the interval is changed only on the next cycle, e.g.

2000 // current interval
2000
...
231 // reset of cycle caused by bang
2000
400 // value sent to train~ immediately before the bang
400
...

Is this a bug or a misconception on my side?