In certain cases where a non-zero pattern loop occurs at the same time as a position jump, pattern break, or pattern delay, OpenMPT performs the wrong action. Here's how the original trackers handle these situations, and how OpenMPT compares (as far as I can tell):

MOD:
PT 2.3d: Loop is not executed, but on every row repetition, the loop counter is started if it's clear (even in the middle of a pattern delay) and is then decremented (I'm pretty sure that's how loop counters work; correct me if I'm wrong). If no pattern delay is present, Bxx/Dxx commands are followed as usual, except the parameter of Dxx is ignored; otherwise, Bxx is followed, and the cursor is then placed one row after the loop start if the loop counter is clear, and at the loop start otherwise. However, if the row has a pattern delay and a Dxx command but no Bxx command and the loop counter clears as the row finishes, then the cursor may or may not instead be placed at the second row of the next order.
OMPT r8219: Loop is executed, and the loop counter is started/decremented once per loop-end encounter, not every row repetition. Upon completion, Bxx/Dxx commands are followed as usual.

S3M:
ST 3.21: If no pattern delay is present, then ST 3.21 seems to handle this scenario just as OpenMPT does. I haven't quite worked out what happens when a pattern delay is present, but I can tell you that the behavior is strange and isn't what OpenMPT does.
OMPT r8219: On every row repetition, the loop counter is started if it's clear (even in the middle of a pattern delay) and is then decremented. If the loop counter isn't cleared on that row, then the loop continues; otherwise, if the loop counter clears as the row finishes, Bxx/Cxx commands are followed as usual if they're present, and if not, then the loop plays once more and the loop counter does not restart upon loop end; otherwise, Bxx/Cxx commands are ignored and playback continues past the loop and skips the next row.

Also, when IT 2.14p5 plays an S3M file, it seems to handle these situations as it does when playing IT files.

XM:
FT 2.08/2.09: Loop is not executed, but the loop counter is started/decremented once per loop-end encounter, not every row repetition. Bxx commands and Dxx commands to the right of the loop are followed as usual, but if none are to the right of the loop, the cursor is then placed at the start of the loop in the target order.
OMPT r8219: Same, except if the row has Bxx commands but no Dxx commands, the Bxx commands are followed as usual, even if no Bxx commands are to the right of the loop.

In addition, and maybe a bit off-topic, if FT 2.08/2.09 encounters a Bxx/Dxx command at the same time as a non-zero pattern delay, regardless of whether a pattern loop is present, it always skips the next row that would otherwise be played, just as PT 2.3d usually does with Dxx commands. OMPT r8219 does not do this.

IT:
IT 2.14p5: Loop counter is started if it's clear, and is then decremented on every row repetition. If any Bxx commands are to the right of the loop, follow Bxx/Cxx commands as usual without starting the loop; otherwise, the loop continues if the loop counter isn't clear yet. If a non-zero pattern delay is present, then if the counter clears as the delay finishes, Bxx commands are followed if they're present and Cxx commands are ignored, and the loop starts again (usually resulting in an infinite loop) if no Bxx commands are present; otherwise, if the counter clears before the delay finishes, Bxx/Cxx commands are ignored and playback continues past the loop. (I really wish I could use markup here to format this better.)
OMPT r8219: Same, except any Bxx commands, even those to the left of the loop, prevent the loop from starting; if the loop counter clears as the pattern delay finishes, Cxx commands are followed if present, and if Cxx commands are not present then the loop plays once more and the loop counter does not restart upon loop end; and if a pattern delay is present and either the loop continues or playback continues past the loop, the next row is skipped.

For all formats here, fine pattern delays don't seem to have an effect on which rows get played and in what order; only regular pattern delays do.