Applied a tentative "fix" in r3819: Searching for an available virtual channel backwards instead of forwards to reduce risk of clashing with "real" NNA channels. I have no idea why this works (because in theory, it shouldn't change anything), but it seems to help for now.

Still happening and I still have no clue why.

I attached a sample that can easily be used to reproduce the problem and a recording of what happens. It doesn't even have to be a looped sample, it just seems like the initial frame of sample playback is cut off, although I'm not aware of any render optimizations that could cause this. To reproduce, the sample should be triggered roughly when it's about to end (try hitting a steady ~ 130 BPM beat).
The slower the module tempo, the more gets cut off of the sample. It's like the sample position is advanced even though the sample is not rendered - but this cannot really happen because the sample position is advanced in the mixer, so if the voice was not actually inserted into the mixer, it should stay at sample position 0. Sample triggering is also guarded by a critical section so it's not the case that a half-constructed channel could be inserted into the mixer.

This age-old mystery is now finally solved in r10802. I suspect that libopenmpt_ext will require a similar fix.