Sadly it seems like there is one of those rare discrepancies between what the WAV writer and the SB16 sound driver does - the SB16 driver is identical to OpenMPT's behaviour, as far as I can see.

I was using the GUS driver for some reason! The SB16 driver and WAV writer behave identically.

Yes, I should note I've been testing with the SB16 driver, where this behavior does occur. Sorry, I'll clarify that in future reports.

It's strange the GUS driver is the one that doesn't do this since that's seems like the one where this would make the most sense.

Yeah, I normally use the SB16 driver as well for testing (it's the most sensible one) - but for some reason, this time when testing the module IT decided to auto-detected the GUS in my DOSBox setup rather than the SB16! Strange...

All the software-mixed drivers share the same loop processing code, so they behave the same typically, but the GUS naturally needs its own loop handling, and I would expect that not too much attention was spent on matching the edge cases between the drivers.

I'm afraid this might be rather tricky to fix - the playback engine currently doesn't allow playing past the end of whatever is currently defined to be the sample loop - among other things, the loop wrap-around buffer would need to be bypassed until we have actually entered the sample loop. at least some of the loop point handling would have to be moved from the player (CSoundFile::KeyOff) to the mixer (Fastmix.cpp).