The application you are pasting into requested UTF8-encoded string, the data found in the clipboard was invalid UTF8 so it couldn't be pasted. I think your guess about UTF-16 is very likely - that RDP / Citrix copies UTF-16 text, but marks it as UTF-8 (or more likely, qubes-gui agent doesn't notice the format and assume it's UTF-8?).
The relevant code is here:

• checking for UTF-8 support: https://github.com/QubesOS/qubes-gui-agent-linux/blob/main/gui-agent/vmside.c#L997-L1015
• there is also some workaround, but it still requests UTF-8 from the application

Can you enable debugging (see qube settings, restart qube after changing it) in the qube you copy from, and then see what gets logged about the time when you copy data?
If that doesn't show anything meaningful, you can also dump secure clipboard content in dom0 (xxd /run/qubes/qubes-clipboard.bin) and post problematic content (but make sure it isn't anything confidential...). That should help find out what is wrong with the content, but we'd still some info from the source qube why conversion failed there.

Thanks for the tips, it also help me reproducing the issue.

Here is multiline text. I can middle click to paste it in a terminal, but I cannot paste it in scite or chrome (middleclick has no effect and right click paste does not paste any content):
00000000: 4669 7273 7420 6c69 6e65 206f 6620 7465 First line of te 00000010: 7874 0d0a 5365 636f 6e64 206c 696e 6520 xt..Second line 00000020: 6f66 2074 6578 740d 0a41 6e64 2061 2074 of text..And a t 00000030: 6869 7264 206c 696e 6520 6f66 2074 6578 hird line of tex 00000040: 74 t

I can confirm that it works with a single line of text however:
00000000: 4669 7273 7420 6c69 6e65 206f 6620 7465 First line of te 00000010: 7874 xt

Is it possible that the \0x0d character alone is breaking things ?

Looking at the code, maybe there is something going on there where several special characters are not considered as valid string:
https://github.com/QubesOS/qubes-gui-agent-linux/blob/02c85aba6f2353fb12dad70b7304ed73807c7267/gui-agent/vmside.c#L1108

https://github.com/QubesOS/qubes-gui-agent-linux/blob/02c85aba6f2353fb12dad70b7304ed73807c7267/gui-agent/encoding.c#L116

@ptitdoc you figured it out! When writing the code, I only considered LF (0x0A) and tab (0x09), but I forgot CR (0x0D). The result is that anything with CRLF line endings is blocked, which probably includes lots of stuff coming from Windows. Unix-like systems use LF line endings, which is why this bug did not get caught sooner.

Patch is straightforward, though I do need to decide on whether to allow CR standalone or only when followed by LF. Standalone CR is relatively rare, but it could happen.

FYI, the purpose of all of this filtering is because:

• Some code might have undefined behavior on invalid UTF-8.
• Certain control characters can be used to bypass bracketed paste mode in terminals. CR is not one of these characters, IIUC.