Atlas Search supports a `searchNodePreference` option in the `$search` stage, which routes all queries that share the same key to the same search node. This improves consistency of scores and pagination (searchAfter / searchBefore) across requests.

Docs: https://www.mongodb.com/docs/atlas/atlas-search/aggregation-stages/search/

{  
      $search: {
          index: "<index-name>",
          <operator>:{ ... },
          searchNodePreference:{ key: "<string>" }
      }
}

`SearchOptions<TDocument>` does not expose this option. I checked versions 3.9.0 through 3.13.0 and the current `main` branch (src/MongoDB.Driver/Search/SearchOptions.cs). The only available properties are CountOptions, Highlight, IndexName, ReturnStoredSource, ScoreDetails, Sort, Tracking, SearchAfter and SearchBefore.

Proposed API

Following the existing pattern used for options like SearchTrackingOptions:

    public sealed class SearchNodePreferenceOptions
    {
        public string Key { get; set; }
    }

    public sealed class SearchOptions<TDocument>
    {  
       //...                
       public SearchNodePreferenceOptions SearchNodePreference { get; set; }
    }

When it is set, the $search stage would render `searchNodePreference:

`. When it is null, the field is omitted, so existing behavior does not change.

Current workaround

We wrap the stage returned by `PipelineStageDefinitionBuilder.Search(...)` in a custom `PipelineStageDefinition<TDocument, TDocument>`. It calls the inner stage's `Render`, injects the field into the rendered `$search` document, and is appended with `IAggregateFluent.AppendStage`. This works, but it depends on the shape of the rendered document. A first-class option would be safer and easier to discover.

Related

The documented `$search` options `concurrent` and `returnScope` are not exposed in SearchOptions<TDocument> either. They could be covered by the same change.