That doesn’t seem sensible. Moving the cursor will confuse bash and you can get the same effect by just omitting the last \n.

Note that bash 5.0, but not earlier or later versions, is buggy with multiline prompts even if they’re correct.

Your colors should use 39 (or 49) for reset.

Avoid doing external commands in subshells when there’s a perfectly good prompt-expansion string that works.

You seem to be generating several unnecessary blank lines, though I haven’t analyzed them in depth; remember that doing them conditionally is an option, like I do:

#PS1 built up incrementally before this, including things like setting TTY title for appropriate terminals
PS0='vvv \D{%F %T%z}\n'
PS1='^^^ \D{%F %T%z}\n'"$PS1"
prompt-command-exit-nonzero()
{
    # TODO map signal names and <sysexits.h> and 126/127 errors?
    # (128 also appears in some weird job-control cases; there are also
    # numerous cases where $? is not in $PIPESTATUS)
    # This has to come first since $? will be invalidated.
    # It's also one of the few cases where `*` is non-buggy for an array.
    local e=$? pipestatus="${PIPESTATUS[*]}"
    # Fixup newline. Note that interactive shells specifically use stderr
    # for the prompt, not stdin, stdout, or /dev/tty
    printf '\e[93;41m%%\e[39;49m%'"$((COLUMNS-1))"'s\r' >&2
    # if e or any pipestatus is nonzero
    if [[ -n "${e/0}${pipestatus//[ 0]}" ]]
    then
        if [[ "$pipestatus" != "$e" ]]
        then
            local pipestatus_no_SIGPIPE="${pipestatus//141 /}"
            local color=41
            if [[ -z "${pipestatus_no_SIGPIPE//[ 0]}" ]]
            then
                color=43
            fi
            printf '\e[%smexit_status: %s (%s)\e[49m\n' "$color" "$e" "${pipestatus// / | }" >&2
        else
            printf '\e[41mexit_status: %s\e[49m\n' "$e" >&2
        fi
    fi
}
PROMPT_COMMAND='prompt-command-exit-nonzero'