Do you have something that exercises this that I could try? I don't have anything to hand right now.

There is an example code in #138

If you change index to 7 in inbox creation, you will see that the box that should be at the beginning of the second line is at the end of the first line without the fix.

        builder.push_inline_box(InlineBox {
            id: 0,
            index: 8, // <--------- HERE
            width: 50.0,
            height: 50.0,
        });

This makes sense to me conceptually. It essentially replicates the code here https://github.com/linebender/parley/pull/163/files#diff-6d9ae7b3a7470dac93dc902558af7eaa8d82c912290e526296707eb14c77c2d1R263 but in the other branch. My head isn't in the code enough to be able to verify that the fix is correct. Probably (manually?) verifying this against a small number of test cases is a good way to go. I'd also be reasonably happy to take @spirali's word that this is a correct fix. We can always revert it if it causes problems.

The whole skip_mandatory_break thing is a awkward hack that it would be good to eliminate when we get a chance. But this seems like a reasonable fix within the current model.

See https://xi.zulipchat.com/#narrow/channel/205635-text/topic/Parley.20implementation.20details/near/440715310 on the motivation behind skip_mandatory_break. To quote:

Nico:

What is the purpose of the skip_mandatory_break variable? It seems to prevent 2 consecutive mandatory breaks from causing 2 newlines (but a 3rd one will cause a secons break). I thought it might be to handle CRLF's, but I now believe those would be combined into a single grapheme cluster and thus would only appear as one break when iterating clusters anyway.

Chad:

I believe the break skipping is a hack to force the actual newline cluster to be bound to the beginning of the next line rather than the end of the current line

Nico:

I see. Why is that desirable? Ah, so that empty lines contain something?

Chad:

And yes, I think it was done so that the final line after a break was non-empty but this might not be the correct way to go. Would be useful to see how browsers handle this
(sorry, I wrote all of this over two years ago :)

I did manual testing while I was trying to understand the problem.

I also run this fix over tests of Nelsie (https://github.com/spirali/nelsie, branch "parley"). Nelsie heavily uses inline boxes and those tests actually discovered this problem. It covers only European languages, but it seems to me that it should be enough in this case.