Thanks for testing, @marctavenier, and you are right that everything should not always be flat like that. Now that I see the code more clearly, I think the list_to_data_tree function isn’t needed for this type of case and I just removed it here:
Now, you even get data tree outputs when you plug in a flat list of input geometries:
And grafting the input gives you a greater level of control, allowing you to get a tree with more sophisticated paths if, for example, you want to separate the core/perimeter geometries of one group of input Breps from another group of input Breps.
This feels like the best implementation since, even if you wanted a flat output, you can just flatten it yourself.