I am not sure if my solution is an acceptable one, but it solves this bug for now. Problem: There were two methods generated and both are written to the mapper class because the selectionParameters in the ContainerMappingMethods are not equal and therefore the methods are not equal and finally both are used.

Good Catch, the question is now what leads to this behaviour? And is your provided solution just a workaround/bandaid for the actual problem. But I tried your solution and it works.
I'm also gonna try and have look what causes this.

Maybe it's something caused by the recursive nature here?
Bean#Beans#Bean#Beans#......
And maybe it would generate even more duplicate methods, but it stops before that because of the first duplicate error

Maybe it's something caused by the recursive nature here? Bean#Beans#Bean#Beans#...... And maybe it would generate even more duplicate methods, but it stops before that because of the first duplicate error

Thanks for the feedback. Yes, the recursive structure of the bean must be the cause, but the MapperCreationProcess ends "successfully" and the duplication error only becomes visible during compilation. At some point, the mapper decides not to create any more methods although the equals method fails.

Edited:
Okay, I may have found the root cause:
In the method PropertyMapping.PropertyMappingBuilder#forge() an IterableMapping is forged, but never inserted into or retrieved from the map MappingBuilderContext#getForgedMethodsUnderCreation(). With this change it seems to work as expected and only one beanListToBeanDtoList method is forged.
I still have to look at the other assignments in the PropertyMappingBuilder#forge().

Edited:

I have added a test for StreamMapping and MapMapping.
It works, but actually both mapping methods are generated twice. However, finally only one method is added to MappingBuilderContext#mappingsToGenerate
Sorry, I have totally missed something. There are actually two methods added for StreamMapping, but it does not lead to a compilation error, because the second method is suffixed with 1: containerBeanStreamToContainerBeanDtoStream1
I will fix this quickly. And I will rewrite the test using GeneratedSource

Okay, everything should be done now. I hope I haven't missed anything.

I still have a question:
All workflow jobs fail with: "Some files do not have the expected license header", what does that mean?

Okay, everything should be done now. I hope I haven't missed anything.

I still have a question: All workflow jobs fail with: "Some files do not have the expected license header", what does that mean?

This is a check if every file contains the copyright header at the beginning of a file.

/*
 * Copyright MapStruct Authors.
 *
 * Licensed under the Apache License version 2.0, available at http://www.apache.org/licenses/LICENSE-2.0
 */

It's working! Pretty cool! :) Lets see what the maintainers have to say

Is this Issue related? #3532

Nice work @Hypnagokali and @zyberzebra. Good catch with the null and empty SelectionParameters.

I pushed one small polish commit. I'll merge this once the build is done

And you are right @zyberzebra #3532 does look identical to this one. I'll close it out