This isn't really a bug; it's rather a malformed module: There is a pattern loop in position 2 / pattern 0 that is never taken due to a pattern break command appearing on the last row of the loop. Due to a replayer bug in FT2 (and also some other trackers, so this behaviour isn't just XM-specific), the pattern loop state is not reset on the pattern transition and the pattern loop will stay active for the rest of the playthrough of the module. So the next time the player reaches the start of the module, it will be in a different state than it was during the first run, and since the state isn't the same the module has to play one more time until it reaches the same state. Technically you are listening to the tune with two completely different internal playback states, but the resulting audio is identical.

It is true that libopenmpt 0.5 and older don't exhibit this behaviour. This is because they don't track pattern loop states during playback. But the new pattern loop state tracking is required for accurate song length calculation and seeking in songs with pattern loops, and in order to detect infinite pattern loops (which previously would have caused some modules to never stop rendering even if you didn't configure libopenmpt to repeat the song infinitely). So there's no way to get the old behaviour back. As said, the module is technically broken in this regard.