Sorry, I got some details wrong the first time around.

Next time, please don't just look at bits and bytes, but also verify that the resulting playback is actually correct - because it is.
OpenMPT always displays pattern breaks in hexadecimal, but in some formats and trackers (like ScreamTracker S3M and FastTracker XM), they are stored and displayed in decimal format. OpenMPT converts between the displayed and internal formats. So D10 in OpenMPT jumps to row $10, and it saves it correctly - if you don't believe me, play your file in FastTracker and you will notice that it will jump to row 16 decimal, as intended.

Yes but I just tested it again in FT2, it has a weird behaviour.
In FT2, D10 really jumps to row decimal 10 (or $0A), but D0F indeed jumps to row decimal 15 ($0F). Once saved, in the file there is $10 for the first case and $0F for the second. But see, in FT2, D15 jumps to row decimal 15 too, and it's saved as $15 (or decimal 22). In FT2, D15 and D0F jump to the same row.

Since I am writing an XM replaying code for a particular system I wonder how I should emulate that behaviour.

That's because the calculation is as follows:

real_row = ((pattern_param >> 4) * 10) + (pattern_param & 0x0F);

As you can see, there are two several values that can be used to jump to row 15 (decimal): $15 ($1 10 + $5) and $0F ($0 10 + $F). Yes it is weird, but it really shouldn't be a problem to implement...

But again, that's not a problem in OpenMPT. OpenMPT stores the value as defined by FT2 in the file, and it will accept both possible encodings when importing XM files.

Thank you very much, and sorry if I (re)opened this. I just tested that both D0F and D15 (as seen in FT2) appear as D0F in MPT, so I'll just implement it like you do.

Alright. Good luck with your further implementations. Doing things exactly like FT2 is horribly painful. ;)