Collections and objects have fundamentally different purposes. An object's job is to anchor a bit of geometry information (e.g. a mesh) in the scene. Collections serve as hierarchical grouping and instancing. Instancing is specifically intended to not produce deep copies of objects. This is essential for creating some types of really complex scenes. Any modifier - destructive or otherwise - requires one or more deep copies to act on. Providing modifiers on collections isn't good UX because it blurs the line between what is and isn't an instance.

Yes, except that you CAN instance collections. You can do linked imports of collections and you can do linked duplicates of collections. And I understand the difference conceptually, but what I'm saying is that the distinction always ends up being arbitrary to me from and actual usage point of view. If I've made a wall or a tower out of mesh data directly, or a collection of objects, it makes no difference to me in regards to my intentions. I have a wall that I would like to instance around my scenes, and I have all the same motivations for wanting to use non-destructive workflow as I would were it an object. If I were to have to combine my collection into an object, it defeats the purpose.

Say I was building a scene like King's Landing. For each building, I'd like to have a file representing that building, that I can instance around a scene representing, say, a city block. I'll do a linked import of the building, so any changes I do to the building will take effect around the scene, and I'd like to make use of arrays and other modifiers for ad hoc instance changes. Again, my motivations for wanting a non destructive workflow are completely the same, regardless of whether that building is an object or a collection.

Now, as of now, my only option is for it to be an object. However, what if I want to use a collection of other objects in order to build the building? I want a cellar door that I'd like to have instanced. I'd like a ladder outside, and a few barrels on the second story. I want these instanced for all the same reasons. My preference, of course, would be for the building to be a collection of all these things, but if I want to then treat my building as one of these such objects at the next higher level of detail, I can't.

So you're dismissive of my intentions by insisting that the difference is meaningful, whereas I simply see it as a failure of abstraction. Objects and collections are ultimately both worldspace coordinates holding mesh data, the only difference is if they're nested at all. And like I said, collections CAN be nested. That relationship is already established. Collections CAN be instanced, that use case is already established. It's really just the modifiers that are missing. And from a programming perspective, the logic of "get the mesh data from the object I've been assigned to in order to apply this transformation" is the only thing that needs to be tweaked. Rather than going one level deep, it will say "and if this is mesh data, stop, else iterate."

I get what you're saying and it's possible to implement all that, but the current workflow is what it is for a reason. Applying modifiers to collections would result in too many UX surprises and pretty bad footguns.

What you want would be less of an issue in a tool that allowed for a more procedural approach where the assembly of complex objects is part of a modifiable construction history that is separate from the final scene graph. In such a context, merging objects is technically destructive, but repeatable. I've written such a modeler once.

You're correct in saying there's no real difference between objects and collections, but there is a meaningful distinction between mesh data and objects, in the object just being a container for the mesh. The modifiers, including array, actually work on the underlying mesh data, not the at the object level, and produce a mesh object as an output. As such, the array modifier does not utilize instancing but actually copies the mesh data multiple times in memory (both RAM and GPU memory), which is definitely not what you want with large, complicated scenes.

So it's not actually about the modifiers being able to be used for what you want in one scenario and not being usable in in a slightly different scenario; the array modifier is not really the tool for the job here at all.

The tool to be used for both of the use cases here is instancing, not the modifiers. Setting up your scene with multiple levels of collections and using proper instancing (which the array modifier is not) certainly is possible, there's just a couple of pieces of the puzzle that you seem to be missing (or unobvious hoops you have to know about, depending how you look at the UX).

Instead of arguing about philosophy and good UX design, I hope you don't mind me elaborating in a more step by step way on how to actually set a scene such as your example up.

You can spawn a collection instance at the location an "empty" type object, by selecting "collection" as the instancing type at the instancing section of object properties. You can have many of these empties and position them manually if you were so inclined.

The other thing is that you can use a mesh to spawn instances of an object at each face of the mesh. So you can create a mesh object, and set up instancing to spawn aforementioned "empty" object, that in turn spawns the whole collection, at each face of the mesh. (You do this by parenting the empty to the mesh, and setting instancing type to "Face" in the instancing panel).

This mesh would typically be rather simple, for example just a couple of disjointed faces scattered where you want your collections to spawn. Or just a single face, and mesh modifiers applied to it, such as array. So instead of arraying the collection, we array a mesh consisting of a single face, and each face of the arrayed mesh spawns an empty that spawns the collection, but the end result is the same. (No idea why each face can't be set to spawn the collection directly and we need an intermediate "empty").

You can also set instances to appear from particle systems etc, for example if you want your houses to just be randomly scattered on a surface of an object (like mesh in shape of the city or so)

Thanks for the tips, although I did know those. Instancing/array is just one functionality. What if I'd like to throw on a lattice to tweak one instance to fit somewhere better? What if I'd like to use the curve modifier?

The point is, the fact that you can do instancing through the workarounds means that there isn't a technical barrier to doing any of this. You say that it would introduce footguns to the UX, but I consider the workarounds to be footguns.

But there is a technical barrier, which stems from what the 'instancing' actually is on the technical level; uploading only one copy of the geometry to the GPU, and rendering it in multiple places, which you can't do if you want to use separate modifier stack for different copies (since modifiers are done on CPU beforehand). The instancing features are ways to set just that kind of instancing up, and as such fundamentally incompatible with separate modifiers between instances of the same geometry.

But yes, I do see the use case for collection level modifier stacks, I just don't think implementing those is exactly as trivial as you figure it out to be. Not impossible either of course (for example by doing some sort of copy-on-write thing if the geometry is modified), but it'd be introducting a different kind of copying mechanism with significant performance differences, which smells a bit footgunny to me

Have you tried geometry nodes? It lets you use meshes from any object, allowing you to build up modifiers non linearly. I would say it covers 90% of the feature you're proposing.

You basically want Cinema 4D mograph. Unfortunately, Blender does not do that at all, unless you use Animation nodes addon, which works, but it's an addon.

There's a major update coming to the geometry nodes feature in 3.0. It does a lot of the same stuff as animation nodes and even has the same lead developer.

Check out Geometry Nodes.

I have, they're super useful. They basically illustrate that what I'm talking about is entirely feasible. In the same way that you can non destructively combine object mesh data into higher order objects, this functionality should be available in the object hierarchy graph.