I've always called the block in #inject:into: the *combining* function.
Perhaps the reason I don't think of it as a "reducing" function is that
setOfSets inject: Set new into: [:acc :each | acc union: each]
has a block that combines its arguments in a way that makes the result
bigger, not smaller.�� For what it's worth, Backus used "insert":
insert-right  /f       where   /f:���x���             =  x
                       and     /f:���x1,x2,...,xn���  =  f:���x1,/f:���x2,...,xn������
                       and     /f:��� ���             =  unit f
insert-left  \f       where   \f:���x���             =  x
                      and     \f:���x1,x2,...,xn���  =  f:���\f:���x1,...,xn-1���,xn���
                      and     \f:��� ���             =  unit f
--- https://en.wikipedia.org/wiki/FP_(programming_language)

Every day spent debating the words is another day the software isn't getting used,
so I'm sorry about prolonging this.�� Some names are just too confusing.
Some years ago, I found it useful to add
�� {value:}...{optionalValue:}...
to my library for passing arguments that the receiver may
choose to ignore.�� (The methods are exactly as direct as
the {value:}... methods, no extra allocations or anything.)
About the same time, Pharo independenty added {cull:}...
but it was years before I noticec, because "cull" to me
means either (a) to slaughter a large proportion of a
population of wild or domestic anmals, or (b) to gather
information from a large number of sources.�� (The concept
"reap" is lurking somewhere in the background.)�� I don't
know who came up with that name for pass-optional-argument,
but it grates so much I can't bring myself to use it and
just make do without optional parameters in Pharo.�� In
fact it was this example that was at the back of my mind.

Changing the subject a wee bit, there's an operation family
in my library, and I wonder how it would fit into Transducers?
To avoid bias, here's a specification in Haskell (for lists,
because I haven't had any luck installing Data.Witherable).

uccessorBy, predecessorBy :: (a -> a -> Ordering) -> a -> [a] -> a
successor, �� predecessor �� :: Ord a �� �� �� �� �� �� �� ��=> a -> [a] -> a

successor = successorBy compare

successorBy cmp x = minimumBy cmp . filter (\y -> cmp x y == LT)

predecessor = predecessorBy compare

predecessorBy cmp = successorBy (flip cmp)

The reason these operations exist is to pick neighbouring
elements in SortedCollections and SortedSets.�� But they make
*sense* for any Enumerable.�� So there are "generic"
definitions with orderrides for those two classes.

A filter + a reduce .�� Traditionally, a #select:thenFold:ifNone:
in order to avoid building an intermediate collection.�� That much
I see how to do with transducers.�� But you can't get the desired
override for #successor:[sortBlock:][ifNone:] by overriding
#select:thenFold:ifNone: in SortedCollection or SortedSet.�� So what
*should* one do?