Regression: by default qemu opens both vnc and stdout console

Host environment

• Operating system: Fedora 34
• OS/kernel version: Linux fedora 5.17.12-100.fc34.x86_64 #1 SMP PREEMPT Mon May 30 17:47:02 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
• Architecture: x86_64
• QEMU flavor: qemu-system-x86_64
• QEMU version: QEMU emulator version 8.1.50 (v8.1.0-2957-g462ad017)
• QEMU command line:

qemu-system-x86_64 \
    -m 4G \
    -smp 4 \
    -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
    -machine memory-backend=mem,accel=kvm \
    -drive file=${image},format=${fmt},if=none,id=iso \
    -device virtio-blk-pci,drive=iso

Emulated/Virtualized environment

• Operating system: Fedora 38
• OS/kernel version: n/a
• Architecture: x86_64

Description of problem

Running qemu with a vnc display (by default I'm not using the -display option) and -monitor stdio, it fails because the display also wants the std output (it fails even if a pass the -vnc option). If I remove the monitor I have both the vnc and the std output console at the same time. I was able to use -monitor stdio, passing -serial telent:...

Steps to reproduce

1. ./configure --enable-slirp --target-list=x86_64-softmmu --disable-user --disable-docs
2. make -j 4
3. qemu-system-x86_64 ... (without -display as shown above)

Additional information

After bisecting I found the following commit changed the behavior:

commit 1bec1cc0da497e55c16e2a7b50f94cdb2a02197f
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date:   Tue Sep 5 23:18:08 2023 +0400

    ui/console: allow to override the default VC

    If a display is backed by a specialized VC, allow to override the
    default "vc:80Cx24C".

    As suggested by Paolo, if the display doesn't implement a VC (get_vc()
    returns NULL), use a fallback that will use a muxed console on stdio.

    This changes the behaviour of "qemu -display none", to create a muxed
    serial/monitor by default (on TTY & not daemonized).

    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
    Reviewed-by: Thomas Huth <thuth@redhat.com>