Needs more work ,but I can submit a patch. Couple issues needs solved first. It’s not updating when the objects in collection changes, unless you change a setting on the modifier.
A setting to see boolean results would be nice. Would keep from having to set each object in the entire collection one at a time.
Edit:
OK, I got it working. I had to make a custom dependency update for that property.
Nice work ! 
Isn’t it possible to use a list of mesh-Data as input ?
Defining how the list is built could be done via GUI
That’s how I’ll do it using python but I’m not sure if the concept of list of object as input can be done in C++
I have some projects on Boolean (mostly performance) that will take me a week or two, but after that I would seriously consider working on getting something like this into Boolean, so please do make a patch when you feel ready. Thanks.
Looks like it works across multiple objects and collections.
Children option on sphere.
Collection with the spheres.
Nice work
I find this quite confusing in a UX standpoint
Children are already inside their own object « collection » So why there’s the need to have a double filter here ? It’s like they need to be in two collections at once
Imo that’s a bit confusing
Maybe this is better. I got rid of Children as target option and added as toggle to limit collection objects to children.
You can see sphere.001 and torus is not used, even though it’s in the same collection.
Not sure if it’s possible but I feel like most optimal ux is to add children as target option and remove collection input field if it’s selected. Then it’s just one click (or no clicks at all and few ctrl+scrolls)
Having to change target to collection, then selecting children collection option in input and then clicking on children check mark is a lot of setup.
Most common use cases are gonna be:
Target Type: Object
Target: Some Object
Target Type: Collection
Target: Some Collection
Target Type: Children
I think it’s safe to assume what we want to use children of our main object and not something else, so there is no reason to expose input field.
I’ve got to admit I’m getting a bit confused now that people are talking about Source and Target. Which is which?
I found the UI in post 11, easy to understand, and have gotten progressively more confused in successive posts as to what the UI was intended to mean.
Another possible UI would be a simple list of objects (not collections), each with an “include” or “exclude” flag that would be present if the operation were Difference. What do people think of that UI?
It’s the same thing. I just renamed source to target. Does it look better expanded like post 11?
The list would work, but I think the use of collections is more elegant here, for a few reasons:
I also like the way that there’s a single operation per modifier here, it makes it easy to tell what’s going on at a glance.
EDIT: Also, maybe “Operand Type” is clearer than “Target”
All fair points in favor of collections. I like that better too, but was just floating another option.
I don’t know what the right answer is for the name of the thing is: “Target”, “Source”, “Operand Type”. In my mind, what it is is “the other operand”, where the first operand is implicitly the object that the modifier is attached to. When it is used in a Difference operation, “Cutter” is a good intuitive name, but for Union and Intersection (and, in my future imagining mind, some Knife-like operations), something as simple as “Operand” or “Other Operand” feels right to me.
Short vid
I got confused too after post 11, especially because of all that children options.
What I understood at the beginning is that a checkmark would allow to treat all the boolean objects in the collection as if they were children, or in other words they would have transforms linked to the main ‘booleaned’ object
Does this explain it better? I removed everything related to children ,since it was confusing. I thought the reason behind it was to be able to move the “cutters” with the modifier object? If you watch the video, it works with the collection option, so no reason really for a third “Children” option. You just need to parent those objects.
This is exactly what I need for comfort CAD production in blender! Waiting for this patch or plugin being available!
I saw that in the video. What the option would be good for is to avoid manually parenting the cutters.
Because of this reason:
Would probably be possible ,but I don’t think the devs are a fan of modifiers changing things on other objects. I have the display option which is useful ,but that will probably get rejected, since it overrides the objects settings.
Indeed the children option was a standalone idea, if we need a double filter then let just drop the idea. it would be quite confusing for the users ?
As I understand, searching for an object children is complicated in C.
Is this related to this bug report https://developer.blender.org/T80432 ? Looks like it might be ,but not sure. Was getting ready to submit patch then discovered one case where a crash happens.
It crashes as soon as you make the modifier cube disappear with the big cube. It doesn’t crash when set to Union, if only the cube is in collection or operand type set to object.
