Wrong container flags on .avi muxing; ignoring interlaced flag

[Selur]

Summary of the bug:
How to reproduce:

1. Take a file with audio and video create separate audio and a video files
ffmpeg -y -threads 8 -i "C:\Users\Selur\Desktop\random.avi" -map 0:1 -vn -sn -ac 2 -ar 96000 -acodec pcm_s16le -f wav -map_metadata -1 "J:\tmp\audio.wav"

ffmpeg -y -noautorotate -nostdin -threads 8 -i "C:\Users\Selur\Desktop\HuffInterlaced.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv,setfield=tff -pix_fmt yuv444p -vsync 0 -top 1 -vcodec ffvhuff -coder 0 -context 0 -non_deterministic true -flags +ildct+ilme -top 1"J:\tmp\HuffInterlaced.avi"

2. multiplex those two files:
ffmpeg -y  -r 30000/1001 -fflags +genpts -i "J:\tmp\HuffInterlaced.avi" -top 1 -flags +ildct+ilme -i "J:\tmp\audio.wav" -c:0 copy -c:1 copy -map 0:0  -map 1:0  -aspect 720:480 -r 30000/1001 -f avi "G:\Output\HuffInterlaced_broken.avi"

3. Checking the flags with mediainfo
mediainfo "G:\Output\HuffInterlaced_broken.avi"
you get:
...
Scan type                                : Progressive
Original scan type                      : Interlaced
...
which indicates that the container is flagged progressive and the video stream is (properly) flagged interlaced. ("J:\tmp\HuffInterlaced.avi" is properly flagged)

ffmpeg version N-113102-gff85dcf033-g0c6203c97a+2 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 13.2.0 (Rev3, Built by MSYS2 project)
  configuration:  --pkg-config=pkgconf --cc='ccache gcc' --cxx='ccache g++' --ld='ccache g++' --extra-cxxflags=-fpermissive --extra-cflags=-Wno-int-conversion --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --enable-ffnvcodec --enable-nvdec --enable-cuda-llvm --disable-doc --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-libaom --disable-debug --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmfx --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-version3 --enable-librav1e --enable-libsrt --enable-libgsm --enable-libvmaf --enable-libsvtav1 --enable-mbedtls --extra-cflags=-DLIBTWOLAME_STATIC --extra-libs=-lstdc++ --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv --disable-w32threads
  libavutil      58. 36.100 / 58. 36.100
  libavcodec     60. 36.100 / 60. 36.100
  libavformat    60. 20.100 / 60. 20.100
  libavdevice    60.  4.100 / 60.  4.100
  libavfilter     9. 14.101 /  9. 14.101
  libswscale      7.  6.100 /  7.  6.100
  libswresample   4. 13.100 /  4. 13.100
  libpostproc    57.  4.100 / 57.  4.100

build using: https://github.com/m-ab-s/media-autobuild_suite on Windows 11 64bit.

Reencoding the video stream would either change the coder and context choice or require the knowledge of which coder and context were used.

I expected that even without having set '-top 1 -flags +ildct+ilme' in the muxing call, that ffmpeg would recognize that the input is interlaced and keep the interlaced signaling of the container.
As a try of a workaround I added '-top 1 -flags +ildct+ilme' to let ffmpeg know that the video is interlaced, but that seems to get silently ignored.

Would be nice if this could be fixed.