Jonathan Kew

Yes, this appears to be a bug; thanks for reporting. I think a workaround would be to add \hskip0pt before the \endL command.

Bug: texlive-xetex/jammy,now 2021.20220204-1 all on Ubuntu 22 requires harfbuzz-1.4.2

Closing this at Karl's request.

xelatex.exe: error while loading shared libraries: icuuc72.dll: cannot open shared object file: No such file or directory

Good to hear it's fixed, thanks.

This is not a XeTeX issue, it's the expected result of how the e-TeX right-to-left support works. For a simplified example, try \TeXXeTstate=1 \hsize 13cm \noindent \beginR \hbox{This horizontal box should contain enough text so that its width is the same a} \noindent \beginR \kern 3cm \hbox{This horizontal box should contain} \noindent \beginR \kern 3cm \hbox{This horizontal box should contain enough text so that} \noindent \beginR \kern 3cm \hbox{This horizontal box should contain enough text so...

I think this is a problem at the macro level rather than in the xetex engine itself. As far as I can see, each \color{...} command here expands into a \special{color push ...} in the output, so that the output driver pushes a new color onto its stack; but the colors are never popped from the stack, and eventually it reaches its maximum size (looks like 128 entries). If you put each usage of \color{....} <text> inside a group, by surrounding it with { ... } braces, the problem goes away because the...

Plain TeX's ~ is just an active-character macro defined as \def~{\nobreak\ }, so my suggestion was simply to make U+00A0 do the same thing.