For example a new constructor of UpdateDocument: UpdateDocument(IEnumerable<UpdateBuilder>).

UpdateBuilder chains do not cover all practical scenarios well. My application creates update pieces for each field separately. Pseudo code:

UpdateBuilder Method1()

{ return Update.Set("filed1", value1); }

UpdateBuilder Method2()

{ return Update.Set("filed2", value2); }

...

As a result, in a method that calls Method1, Method2, ..., MethodN I have a collection of update expressions, one per a field. The driver does not provide an easy way to join these pieces into a single update expression to be used in Update() methods. Instead, we have to create a starter empty UpdateBuilder, send it to all methods, and methods have to be a bit more complex:

UpdateBuilder Method1(UpdateBuilder builder)

{ return builder.Set("filed1", value1); }

UpdateBuilder Method2(UpdateBuilder builder)

{ return builder.Set("filed2", value2); }

...

""""" Real scenario: it shows that even Method(UpdateBuilder) approach is not enough for all """""

In fact, my application is a PowerShell module designed for MondoDB + C# driver.
In scripts I would like to be able to perform commands like this:

Update-Data $collection $query @(
Set-Value filed1 value1
Set-Value filed2 value2
Set-Value filedN valueN
)

The last argument of Update-Data cmdlet (it calls Update() on $collection) is a collection of update expressions produced by one or more calls of the Set-Value cmdlet (gets an update expression for a single field).

But this desirable code is now not supported due to lack of a proposed driver method. I cannot even use Method(UpdateBuilder) approach because the expression @(..) is evaluated before the call to Update-Data and there is no chance to initiate a starter UpdateBuilder to be sent to Set-Value cmdlets even implicitly (say, as a hidden internal variable shared between Set-Value calls).

Instead, I have to make the Set-Value cmdlet to accept optional UpdateBuilder input via pipeline. So that I have to emulate UpdateBuilder chains in a peculiar way. And the code above right now actually has to look like this:

Update-Data $collection $query ( `
Set-Value filed1 value1 |
Set-Value filed2 value2 |
Set-Value filedN valueN
)

So that the first call to Set-Value initiates a starter UpdateBuilder and sends it to other Set-Value-s. The required UpdateBuilder chain is emulated.

Well, it is not that bad and the job is done. But it is not pretty either:

*) Pipelines (|) are basically expensive in PowerShell and better be avoided
*) Syntax is not so easy and neat like it could be (version 1 is much better)
*) It all gets more difficult if a script wants to call these Set-Value in different places, collect results in some $updates variable (a collection) and then only to call:

Update-Data $collection $query $updates

""""""""""

Of course, I can go to lower level and do that $set, etc. things on my own. But I think the purpose of the driver is to do such low level jobs and let users to concentrate on their application code instead. Ideally, a user of C# driver should not have to know MongoDB query/update expression syntax details.