That's an interesting edge case. Essentially it happens because, when the sample is about to reverse, its playback position is exactly at the end of the loop, which is normally relatively unlikely to happen but in this case it will happen for most C notes because the mixing rate (48000 Hz in your case) and sample rates will be exact multiples of each other, so the sample playback position will always be exactly at the loop end when it's about to reverse. If you set the mixing rate to 44100 Hz for example, this won't be the case because the sample position may be close to the loop end when it reverseds but not precisely. It also works if you load the sample into an older module because OpenMPT 1.30 has a new ping-pong loop handling system and sample positions will be slightly different when the playback quirk for emulating older OpenMPT versions is enabled.

Interesting indeed.

Until an update is available, you can also enable the playback compatibility setting "Do not repeat last sample point in ping pong loop, like IT’s software mixer". It will slightly alter bidi loop behaviour but the effect is mostly observable with chip samples, so not really relevant in this particular case.

Fixed in r17346.