Same output in screen and without screen:

$ printf 'xA\U0000030Ax\n'
xÅx
$ printf 'xA\U0000030Ax\n' | hexdump
0000000 4178 8acc 0a78
0000006

Tested in xterm, Xfce Terminal and Terminology.

Please test it again. It seems fixed in 4.9.0.

Mike, does this behavior cause any actual bug? Looks to me that it should be harmless.

My wild guess is:

It could be related to https://bugzilla.gnome.org/show_bug.cgi?id=673981 bullet point 3, and the varying behavior of terminal emulators in that case.

When screen sees the first "A", it decides that it needs to print that, and does so.

When it encounters the combining accent, it updates its internal concept about the screen contents: it's no longer an A but an A with some combining accent.

Maybe it totally forgets that there was already an "A" printed that could be reused. Or maybe it still recalls that there's an "A" there, but didn't keep track whether the cursor was perhaps moved away (e.g. to update something on a different pane) and then moved back, according to the bullet point 3 of the aforementoned bug. Either case, it cannot be sure that simply printing the combining accent will properly go over the corresponding base character, so decides to reprint the character.

So it's not necessarily an explicit '\b' for this purpose somewhere in the source, maybe it's just the simplest way of moving the cursor to that desired place.

screen should, however, probably consume the entire input in a single step, and then update the canvas in another single one, in which case this trick wouldn't be necessary.

All these are just a random guess from me, without knowing anything about screen's internals. I just guess that the real explanation might be somewhere along these lines.

i tried a few diff terminal emulators and observed the same behavior

on a completely different system i tried screen 4.6.1 and it did not insert \b into the stream.  not sure if it's because of the upgrade or because of some other system aspect.

i guess if you know of a change that went in to change this behavior, it's fine to punt the bug.

simple example:
  printf 'xA\U0000030Ax\n'

that will write out the UTF-8 byte stream (hexdump view):
  78 41 cc 8a 78 0a  |xA..x.|

when i'm not using screen, the terminal emulator sees that exactly.  however, screen will read that and then mangle it, passing along:
  xA\bA\U0000030Ax\n
  78 41 08 41 cc 8a 78 0a  |xA.A..x.|

a proper terminal emulator is able to deal with this.  but the question still stands: why is it doing this ?  i couldn't locate the logic in the screen source though.

poking it through strace shows the screen process doing the read() on the pty master (/dev/ptmx) and getting the correct UTF-8 stream, then doing a write on its slave pty with the mangled stream.  so it doesn't seem like it's an external-to-screen mangling.

my locale is set to en_US.UTF8, screen was launched with -U, and .screenrc has:
  defutf8 on
  defencoding utf8
using screen 4.05.00

since the whole pipeline is UTF-8 aware, i can't explain why screen would need to interject these things.  i might understand if it was dealing with some semi-broken systems where it tried to get slightly better output, but that doesn't apply here.

the odd thing is that when screen dumps lines from its history (e.g. when you attach or otherwise scrollback), it doesn't inject the \b logic.  only for new content.

noticed originally with a bit more pathological line:
1.001.01a अ॒ग्निमी॑ळे पु॒रोहि॑तं य॒ज्ञस्य॑ दे॒वमृ॒त्विज॑म् ।
that inserts a number of \b (all around combining chars?  didn't look super close).