Yes, I understand about the delay being compensated at the end of the interval, and that’s something I tried to mention and acknowledge in my second paragraph.
The delay is not affecting the quality of my training, and on that basis you could reasonably say that it’s not worth worrying about. On the other hand, if we accept it’s only a problem of syncing the period of stabilised power with the interval timing, the TR software should not bother to show me power averages for the interval, or the little ball either, if those averages aren’t correctly reflecting the period of time where the trainer is settled in at the target power.
If TR is sending the target power to the trainer 1-2 seconds earlier, as mentioned in an earlier post, then that shows the software developers already think it’s important to have the load generated by the trainer nicely synced with the interval start time. I accept that’s difficult to get right though, because it’s trainer-dependent and gear selection dependent.
My suggestion, to throw away the first few seconds of power data (only for the purposes of average power data) I think would be an easier alternative. It’s the first thing I would modify if it was my software, because I imagine it’s just a few lines of code that does the averaging and controls the ball. It would fix something that is a little bit annoying, to me at least, at quite low cost.