An assemblage (from French agencement - arrangement, fitting) is a collection of things (parts) which have been gathered together or assembled entertaining mutual relations and information exchange. Other than the parts themselves, their connections, the arrangement of those connections and the interactions among parts concur in determining the identities and properties of the whole.
In an assemblage, a part retains its individual identity, but because of the relations it entertains with other parts, it acquires further meaning and participates in the formation of larger, shared identities. The same part can acquire diverse meanings and form disparate identities if extracted from an assemblage and plugged into a different one.
Assembler is aimed at the design of... you guessed it, assemblages. Not aggregations. Not aggregates.
"Well.. aren't they the same thing? Or at least synonyms?"
No, they are not.
Without involving the philosophical origin*, the main difference is that aggregates focus on parts alone, while assemblages focus both on the parts AND the relations these parts establish with each other for the construction of complex order. Their topology is an essential key for their computability as complex objects (basically: how does information circulates and it is distributed). I’m not dismissing the relevance of aggregates, but they are not the same things as assemblages. It is a matter of perspective more than objective qualities alone: sure, piles or heaps of objects with no relation to each other other than proximity or friction are definitely aggregates (and it’s hard to see them as assemblages), but very structured and ordered rule-based constructions can be addressed as either aggregates (if one focuses mainly or solely on the role of parts) or assemblages (if the relations and dynamics are just as important as the parts).**
“Isn’t this nitpicking?”
Well, yes and no.
Like I said above, it’s a matter of perspective: if we observe outcomes from a purely external stance, as nothing more than objects, then I guess the difference I outlined above doesn’t matter much. And, for a casual and playful use of this plugin, it doesn’t either. But if we want to enter a more accurate understanding of the architectural implications and potential, the difference matters a great deal.
** on this note, see: Alexander, C., Systems generating systems, in **Menges, A & Ahlquist, S 2011, AD Reader: Computational Design Thinking, John Wiley & Sons Inc, London, pp. 58-67