Investigated this a bit more. 
SUMMARY
It is actually not the number of audio tracks in the original clips, but the number of audio tracks available in the time-line that are rendered. And they are rendered, as long as they show in the time-line, even if empty, even if muted. 

STEPS TO REPRODUCE
1. Have a time-line of three video and 4 audio tracks
2. Import a clip with one video track and two audio tracks
3. Render  “Separate file for each audio track”

OBSERVED RESULT
The rendering results in one video track and five audio tracks

EXPECTED RESULT
Rendering produces one video track and two audio tracks

REMARKS
This is not logical in comparison with the handling of (empty) video tracks. 
It would be cumbersome if I had to always change the number of tracks in the time-line view to avoid this problem, and long rendering times.

I confirm this is the case. Kdenlive renders the video for each audio track even if the audio track is empty. At the very least there should be a warning message or a dialog where you can select which audio track you want included (I can imagine a use case where an empty audio track is needed).

This is illogical and inconsistent. Why should video tracks be handled differently from audio tracks?

My suggestion: very straightforward and comprehensible: Either single output file; or "All enabled video|audio tracks are rendered into separate files each". That requires two choices, naturally, for video and audio. Instead of actually having to delete tracks from the time-line, setting rendering on/off is done by enabling/disabling the respective track. I am convinced that this would be the most versatile method. 
This also supports any eventual use case of empty tracks: you enable the track, but leave it empty. In my case, I can easily drop any input (my files range from one to four audio tracks) into the always same time-line, keeping synchronism, and finally disable those that I don't want to be included into a single output file OR separate files.

(In reply to Uwe Dippel from comment #3)
> This is illogical and inconsistent. Why should video tracks be handled
> differently from audio tracks?
It's not illogical nor inconsistent. Video tracks are always composited together because in any container there is only one video track (AFAIK). On the other hand, there can be multiple audio tracks or channels, so it makes perfect sense to handle them differently.

> My suggestion: very straightforward and comprehensible: Either single output
> file; or "All enabled video|audio tracks are rendered into separate files
> each".
IIRC, you can "disable" video tracks so that they are not used in preview and final render. I know the same can be done for audio tracks, and I need to test whether a muted audio track is not taken into consideration when switching on 'Separate file for each audio track'.

(In reply to Bernd from comment #4)
> I need to test whether a muted audio track is not taken into consideration when
> switching on 'Separate file for each audio track'.

Didn't work, neither did making audio tracks inactive ...

Ok, so my idea for this would be to exclude the muted audio tracks (the tracks that were muted by the user by clicking on the "Mute" icon) from rendering with the "separate tracks feature". Would that solve the problem ?

Ooops, I think that's exactly what I meant in #c3. 
Controlling the render process by forcibly having to remove tracks from the time-line would be just rough. That should be the purpose or result of 'mute' (in my comment called enabled/disabled). I find it  most inconvenient having to change the track layout in order to avoid rendering. Mute-ing respectively disabling (the mouse over says 'Hide', which is suboptimal, because one doesn't hide that track) is the most logical point to include/exclude a time-line track from the final result.

(In reply to Jean-Baptiste Mardelle from comment #6)
> Ok, so my idea for this would be to exclude the muted audio tracks (the
> tracks that were muted by the user by clicking on the "Mute" icon) from
> rendering with the "separate tracks feature". Would that solve the problem ?

I agree that's the best way forward as it uses existing functionality and logic and extends it to the audio track.

I would still vote for implementing the following change: If the user selects 'Separate file for each audio track' there is no audio downmix in the video file but indeed separate files for the video stream and audio streams. The user must mux them later.

(In reply to Uwe Dippel from comment #3)

> It's not illogical nor inconsistent. Video tracks are always composited
> together because in any container there is only one video track (AFAIK). On
> the other hand, there can be multiple audio tracks or channels, so it makes
> perfect sense to handle them differently.

That's your opinion. For me it looks the other way round. There are use cases for empty tracks, there are cases (most) where you have a single video track. I myself remember a project, where I had multiple video tracks that needed rendering of more than one separate video tracks. Then, they had to be enabled/disabled, saved under another name, and rendering to be restarted. 
The topic 'multiple video tracks in a single container' isn't the staple one, but has been discussed for quite some time. MKV for example, does that easily. 
I do agree, there should be a warning once a user runs into this situation, asking if this is really what he wanted, because players usually do not support this.. The default would always be mixing the streams together. But that's not much different with audio. 

From the average user perspective, we always try to construct the UI such that the user doesn't have to know, think, ponder; rather straight forward handling, with as many as possible duplications and similar implementations of an interface. 

I had started working on, later with, FOSS 25+ years ago. And was so frustrated that all our great stuff wasn't really appreciated by the general public. I've learned why. My favourite editor is still vi. And I know I'd be a bore telling my wife how great it is. HCI must never be seen from the insider perspective.  
Though I stop before deviating too far off the topic.

Git commit 9983f74625abbac7288898db2f79db679befbca4 by Jean-Baptiste Mardelle.
Committed on 03/08/2024 at 10:30.
Pushed by mardelle into branch 'release/24.08'.

Separate file for audio tracks fixes: Fix muted tracks exported, don't export audio for video render

M  +44   -23   src/dialogs/renderwidget.cpp
M  +1    -1    src/dialogs/renderwidget.h
M  +20   -3    src/render/renderrequest.cpp

https://invent.kde.org/multimedia/kdenlive/-/commit/9983f74625abbac7288898db2f79db679befbca4

So I just pushed the change to do the following:
- do not export muted tracks
- no audio in the video render if separate audio tracks is enabled.

I think it fixes the original issue reported here.
Regarding exporting separate video tracks, this seems a rather uncommon scenario but is more a feature request than a bug.

(In reply to Jean-Baptiste Mardelle from comment #11)
> So I just pushed the change to do the following:
> - do not export muted tracks

Checks

> - no audio in the video render if separate audio tracks is enabled.

I do see use cases for this, too. So it should rather be the choice of the user, if he wanted a remix of audio with the video plus separate tracks, or not. I agree, this is a feature request. 

> I think it fixes the original issue reported here.
> Regarding exporting separate video tracks, this seems a rather uncommon
> scenario but is more a feature request than a bug.

Agree, definitively. 

Still, we ought not try to stand in the users' shoes. 'Uncommon' doesn't equal 'makes no sense'. I was thinking of identical sequences with clear and pixelated faces. Mixing down would be silly. Of course, one can enable-disable-render-change output file names-etc. What's wrong doing one edit, same edit points, same effects, and have a video for the public with privacy protection, and an inside one without? 
As an example. Just to show that there is nothing wrong with multiple video files.

(In reply to Jean-Baptiste Mardelle from comment #11)
> So I just pushed the change to do the following:
> - do not export muted tracks
> - no audio in the video render if separate audio tracks is enabled.
> 
> I think it fixes the original issue reported here.
> Regarding exporting separate video tracks, this seems a rather uncommon
> scenario but is more a feature request than a bug.

Yes, looking forward to get it propagated into my distribution, ppa, or whatnot.

For the meantime, I'd like to include the ffmpeg command to do all in a single go: remove the re-mixed track, and add (e.g.) the two audio tracks. Here it is:
$ ffmpeg -i Rendered.mp4  -i Rendered_Audio_1.mp4 -i Rendered_Audio_2.mp4 -map 0 -map -0:a -map 1:a -map 2:a [-metadata:s:a:0 language=fra -metadata:s:a:1 language=eng] -c:v copy -shortest Output.mp4

-map 0 maps all tracks
-map -0:a removes all audio from first file
-map 1:a adds the audio from ...Audio_1.mp4
-map 2:a adds the audio from ...Audio_2.mp4
[everything in brackets] is optional, and would include language indications, e.g. for VLC to select the respective audio language
-c:v copy copies the video without encoding
-shortest adjusts eventually slight length differences, taking the minimal length for the output file

@Uwe Dippel

Please open a new Bug for “exporting separate video tracks“ so we can track it separately.

I close this bug. If the original issue still appears in the latest version, please feel free to re-open it and update the affected version number.

Yes, closed, fixed. 24.12.0.
I wouldn't want to reopen for a very minor item: Until now, rendering would inform us about some "audio track without video" respectively "video without audio". Here, the video track in the render window  is silent; in the best and literal way about this fact.
W.r.t. consistency, I'd suggest to include this information. Or drop it on all similar occurrences, assuming the user knows best well what he has set.

Thank you for your feedback.