Digging in to this a bit more after the initial patch in bug 1507744, I think there's a better solution. We don't actually care about whether the text run construction spans the inline boundary; what's important is the word-break setting passed to the nsLineBreaker, and the extent of the text that it treats as a "word" for the purpose of marking potential break positions. Any given "word" (generally, space-delimited run of characters) will be handled using the mWordBreak setting of the line-breaker.
The line-breaker accumulates text independently of where text-run boundaries occur, so that even if, say, a single letter in the middle of a word is <b>bolded</b>, the word will be handled as a single unit for line-break computation. This is important in order for things like hyphenation to work properly.
So what we need to do here is to check for when the word-break value changes, and at that point, flush any "current word" the line-breaker is accumulating, independently of whether there's a text-run break. Then we can reset line-breaker's mWordBreak for the next fragment.
By not interrupting the text run when word-break changes, we'll avoid disrupting any shaping such as ligatures or kerning that might apply across the inline boundary.
(This is still not strictly perfect, as it means word-break changes within a word will interfere with hyphenation of that word. In practice, though, that's unlikely to be an issue: word-break is primarily used to control breaking in CJK text, where hyphenation isn't used anyway. And its other value word-break:break-all, which is sometimes used with Latin and similar scripts, makes hyphenation superfluous.)