I think the glitchy nature of mark/Jump at times often comes down to this issue...

The sequencer will try to send out ALL the Program changes, volume commands, and other controllers that it back scans for on the 'One' of the next section, which can often (if there's a lot of them) interfere with the timing of any notes that are ALSO on the 'One' (which is pretty much all of them!).

I think a better system would be to play these PC#'s and controllers on the LAST 1/16th (or 1/8th, whatever works) of the PREVIOUS section, where you wouldn't hear them very much, and they wouldn't interfere at least with the TIMING of the notes on the 'One'.

You might also have issues with some arrangers, that still cut off the sound of a previous Tone when changing to a new Tone, making the glitch no matter what you do to mitigate when the PC# is called for. Fortunately, Roland's have long (I mean LOOOOONG!) been able to change Tones utterly seamlessly, and I for one have far fewer issues with any glitches at Mark/Jump boundaries.

If you plan carefully, and try to avoid having MIDI channels with Program changes on them (most sequencers can split a multi-sound track into separate ones for each sound - as long as you don't end up exceeding 16 tracks, you are good to go), you can avoid most of the glitch pitfalls.