1. What would you like to communicate to the user about this feature? we’ve decided to abstract the merge functions by changing the options builder pattern to maintain a slice of setter functions, rather than setting data directly to an options object. Typical usage of options should not change, for example the following is still honored: opts1 := options.Client().SetAppName( "appName" ) opts2 := options.Client().SetConnectTimeout(math.MaxInt64) _, err := mongo.Connect(opts1, opts2) if err != nil { panic(err) } There are, however, two notable use cases that will change for users. Modifying Fields After Building The options builder is now a slice of setters, rather than a single options object. In order to modify the data after building, users will need to create a custom setter function and append the builder’s Opts slice: opts := options.Client().ApplyURI( "mongodb: //x:y@localhost:27017" ) // If the username is "x" , use password "z" usernameSetter := func(opts *options.ClientOptions) error { if opts.Auth.Username == "x" { opts.Auth.Password = "z" } return nil } opts.Opts = append(opts.Opts, fn) Creating a slice of Options Using options created with the builder pattern as elements in a slice: opts1 := options.Client().SetAppName( "appName" ) opts2 := options.Client().SetConnectTimeout(math.MaxInt64) // Option objects are "Listers" in V2, objects that hold a list of setters opts := []options.Lister[options.ClientOptions]{opts1, opts2} _, err := mongo.Connect(opts...) 2. Would you like the user to see examples of the syntax and/or executable code and its output? This is not necessary since the general use case will not change. 3. Which versions of the driver/connector does this apply to? V2