I took a leaf out of the book of dealing with octal escapes in string literals in the C language. One of the simplest ways of avoiding the problem of the octal number in the escape being followed by an actual intended digit character is to terminate the string literal and start a new one. Hence:
"abcde\001""23"
I took the same idea and applied it to pasted content. When console-terminal-emulator receives ESC or CSI characters from its input FIFO that are marked as pasted text, immediately after sending them on it sends an end-of-paste sequence (DECFNK 201) followed by a start-of-paste (DECFNK 200). Thus any potential DECFNK control sequence in the pasted text, that would otherwise itself turn pasting on and off, is broken up.* http://jdebp.eu./Softwares/nosh/guide/console-terminal-emula...
For example: Generating the sequence ESC [ 2 0 1 ~ l s LF as pasted input directly to the terminal emulator's input, in the way that a realizer program would send pasted input events, with
# printf '%c\x00\x00\x09' $'\x1B' '[' 2 0 1 '~' 'l' 's' $'\n' >> /run/dev/vc2/input
results in user virtual terminal #2 receiving the following % printf "\x1b[?2004h" ; cat -v
^[[200~^[^[[201~^[[200~[201~ls
Breaking that down, those are:1. DECFNK 200 (start pasted text mode)
2. ESC (as pasted character)
3. DECFNK 201 (end pasted text mode)
4. DECFNK 200 (start pasted text mode)
5. [ (as pasted character)
6. 2 (as pasted character)
7. 0 (as pasted character)
8. 1 (as pasted character)
9. ~ (as pasted character)
A. l (as pasted character)
B. s (as pasted character)
C. LF (as pasted character)
A Z shell running in that terminal does indeed receive this as the pasted text ESC [ 2 0 1 ~ l s LF, exactly as sent, and does not enact the embedded end-of-paste or Line Feed.