You will in fact find that the latest test versions of XMPlay will behave the same. This is happening due to on-the-fly sample swapping. The module was probably written in FastTracker 2, which is one of the few widespread MOD-compatible trackers that don't implement this at all. You can disable on-the-fly sample swapping in the song properties in OpenMPT, but it won't get saved to the file, and in libopenmpt-based players there is currently no way to turn it off either. Since other tunes require this behaviour, it's hard to tell heuristically when it should not be applied. Maybe I can come up with an improved heuristic but don't hold your breath. :)

I realized that the on-the-fly sample swap detection heuristics was actually bypassed since 0000754 was fixed, so it was applied unconditionally. I have now modified the behaviour to always use on-the-fly sample swapping for Amiga-compatible modules and resort to the heuristic for all other modules (like slow-funk.mod). The new behaviour is available as of r11395. I want to gain some more confidence in this before merging this back into OpenMPT 1.28, so please report if any other MOD files no longer play as intended.

So FastTracker 2 allowed you to save four channel Amiga modules with its additions used, similar to ImpulseTracker with S3M?

There are no additions, just different interpretation of pattern data - in this particular case, the author entered some bogus instrument numbers without notes next to them into the patterns, which doesn't do anything in FT2 in this particular case, but in fully ProTracker-compatible players, the new instrument is played. FT2 is not the only player doing this, I think ST3 would for example do the same.

I still have quite a lot of modules to test, but the ones I've tested so far seem to be behaving normally.