I just tested in Terminal.app (macOS) with zsh and several things happen: If you do nothing but run `echo -n 'hello world'` and then resize the window, the next line prompt will be jittery (it'll jump left and right as you resize but ultimately return to the correct position). My prompt is "14:41:44 ~ ️ <cursor>" and if I resize fast enough, the previous line (the one with the output `hello world%` starts displaying characters on the right side. Characters from the next line. If I do it fast, it becomes obvious what it's doing: Fragments of the next line is copied to the previous line, so the right part of 'hello world%' is filled with: `111141414:314:3914:3914:39:` after a few resizes.

If you press return again (executing no command) then the buggy output is now fixed and no magical behavior occurs.

It may be easier to just see, so here's an example: https://www.loom.com/share/5eab7cfb4590475a8881fe3e91d92738

My understanding is that zsh registers a signal handler for SIGWINCH and that handler fixes things up.

    --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
    rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [WINCH], 8) = 0
    rt_sigprocmask(SIG_SETMASK, [WINCH], ~[KILL STOP RTMIN RT_1], 8) = 0
    ioctl(10, TIOCGWINSZ, {ws_row=45, ws_col=108, ws_xpixel=756, ws_ypixel=585}) = 0
    getuid()                                = 1000
    geteuid()                               = 1000
    capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
    capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, inheritable=0}) = 0
    ioctl(10, TIOCSPGRP, [20139])           = 0
    ioctl(10, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
    ioctl(10, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
    ioctl(10, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
    write(10, "\r\r\33[0m\33[27m\33[24m\33[J\33[44mubuntu@i"..., 90) = 90
    rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)

It essentially queries the new window size, and then writes a new prompt beginning with two carriage returns.

It depends if you make it bigger or smaller and if the line break was missing or not. Under some combinations of those two parameters, previous lines overflow with white space.

Mostly, terminals don't reinterpret old escape sequences whe resized. xterm and alacritty just cut off text from the right of the window. rxvt-unicode can reflow long lines but seems to preserve it nicely. Presumably they accounted for carriage-return following wrapped text and have that move to a new line in their buffer. I can get it to glitch from inside a tmux.

Zsh will only do anything about the current active prompt on SIGWINCH. Old prompts back in the scroll buffer can't be redrawn even if zsh wanted to. And while a different command is running, even something like `sleep` will do if you're testing, that command has control of the terminal and it, rather than zsh, receives SIGWINCH.

The COLUMNS variable is kept in sync with window size in any decent shell on any decent kernel that has SIGWINCH and struct winsize.