The problem here is not that OpenMPT is wrong; the problem is rather that it used to be wrong in the past. :)

The original IT source file was writen with ModPlug Tracker 1.16 or maybe an early OpenMPT versions. The MO3 converter sets a flag to tell the player that the file should be played like MPT; but that's all the information we get. It doesn't tell us which version of MPT was used to write the file, so we can only guess which compatibility flags to disable. Currently we do not use this information at all, but maybe we can make an educated guess based on the MO3 version (this is a MO3 v1 file, so probably 10+ years old).

That would probably be correct, the game was made somewhere around 2007.

Ah, in that case it was most likely written with OpenMPT 1.17, which is known for putting those pesky instrument numbers next to note-offs, which is the source of the trouble here.
If you want to listen to the track in OpenMPT/libopenmpt, you can go to the compatibility settings and remove the checkbox next to "Instrument number with note-off recalls default volume" (third option from bottom at the time of writing) and re-save as IT to get this instrument to sound correct. Technically you can uncheck all of those boxes, as all but maybe two of them would be disabled if OpenMPT realized that the file was created with version 1.17.

Incidentally, this appears to be the only fully tracked module in the soundtrack, so if you end up going the Operation Stealth root and working around issues in this module, it should be the only tune you'll have to worry about.

Well, there difference between the SFX and MO3 case is that there are many MO3 files around, and there are people still creating new MO3 files, so it's harder to apply file-specific patches there. And it would be wrong, because we know that there are probably dozens of other MO3 files out there with the same problem. The correct way to fix this is to apply the "play like ModPlug would" flag from the MO3 header, but I will first ask Ian from un4seen which playback behaviours this flag should be applied to. There will be a fix, just don't expected it to be done in the next few days.

Note: This is being handled in https://www.un4seen.com/forum/?topic=18350.0 - seems like XMPlay handles this playback quirk wrongly no matter if the file was originally created with OpenMPT or Impulse Tracker.

So, the outcome of this is: OpenMPT now respects the "modplug mode" flag in MO3 files, however this doesn't with that specific file because the flag is not set here. XMPlay's own playback quirk is now also fixed, meaning that the file will also sound broken in XMPlay and other BASS-based players. Since there is no clear indication in the file that it was made with ModPlug (stereo samples and extended filter range are also supported e.g. by BeRoTracker), I am not sure we can heuristically make this working again. Since the file is essentially broken, I would advise to re-save it as an IT file, but apply either of those two fixes:

• disable the "Instrument number with note-off recalls default volume" compatibility setting in the song properties (only works for libopenmpt-based players)
• remove all note numbers next to note-offs (works in all players)

I'll close this as it basically just plays as intended. Please use the workarounds described above if you want to listen to the song in either OpenMPT or current XMPlay versions.