The $set stage and $set update operator factories both take named arguments for field names:

set(foo: 'bar', baz: 1)

Since named arguments cannot contain dots or dollars, nested field paths need to be destructured from an array:

set(...['foo.bar': 'baz'])

To work around this limitation, we could consider introducing a separate API, where two values are passed:

set('foo.bar', 'baz')

The first argument would be considered the field path, the second argument is the value to set. This could be expanded to allow multiple such pairs being passed:

set('foo.bar', 'baz', 'baz', 1)

For update objects, the current logic already collapses multiple operators of the same type. For pipeline stages, the query optimiser in the server collapses multiple subsequent $set stages into a single stage.

The main concern here is having two different APIs in the same factories, so we may want to consider introducing separate factories for this style that generates the same operator classes. Alternatively, the parameter definition should be adapted to clearly specify the different call styles.