That particular conundrum I thought I'd cracked a while back, but today somebody pointed a situation where Drum Score Editor doesn't behave itself properly.
Looking at the 3rd phrase, which is musically identical to the second, Drum Score Editor behaves itself. This identifies the issue as being when a note is beaming back to a prior note, the logic used is incorrect.
As a quick workaround today, editors can drop the beam back from the misbehaving note. In the meantime I'm adding some logic to the code that is a simple rule: if the note is beaming back to the prior, and the prior note is not dotted, then the note should look forward to calculate how many excess tails it has, and draw forward appropriately.
This doesn't change the existing logic that says if the note isn't beaming back always consider forward.
Probably time for a complete refactor of all the logic for beams and cuts, similar to the overhaul unison logic and drawing received in version 2.7, however that will take some effort so for the interim watch for a version 2.73 in the next few days, time permitting.