Although this seems not too-meaningful for folds and scans (and I have the expressed opinion by @adamretter saying "I agree that fn:fold-left and fn:fold-right functions should not have index arguments.) ", I would not object to this if the additional argument is in a separate overload. Thus, if we have two separate overloads, the first one as is now - with the $action argument being a function of 2 arguments, and the second one with the $action argument being a function of 3 arguments.

Combining these two overloads into a single one is not only formally problematic, but also requires unnecessary mental gymnastics for the reader to clearly understand the specification, when this issue would completely be non-existent if we had two separate overloads.

Consistency is very hard to achieve in a language designed by committee, but it's not acceptable to have two different functions do the same thing in different ways just because they were put forward by different people. If we make a change to the way this is done, it needs to be done across the board, not just in one function.

Consistency is very hard to achieve in a language designed by committee, but it's not acceptable to have two different functions do the same thing in different ways just because they were put forward by different people. If we make a change to the way this is done, it needs to be done across the board, not just in one function.

Microsoft is a good example of producing a language that is not designed by committee, and yet they decided not to add an overload where the $action argument is a function that has the position in the collection as an added new argument.

Why Microsoft didn't do this in the specification of Enumerable.Aggregate method ?

Not because they missed something (we are at ver. 8 of .NET, and LINQ was introduced almost 20 years ago - in ver.3, so they have had plenty of time to notice and correct any omissions), but because they decided (as both @adamretter and I concur) that this has little meaning, if any at all.

In addition, we should add array:scan-left and array:scan-right. My suggestion would be to be less paternalistic and align the result types of fn:scan-(left|right) with fn:for-each, and to use the array functions for structured results. Of course, nothing prevents a user from creating structured results with fn:scan-(left|right) as well.