Split out of CSHARP-5996 (Investigate and remove all Obsolete APIs). That ticket removed the obsolete public surface that could be deleted mechanically; this cluster was deliberately left behind because it is still functional and removing it is a behaviour decision rather than a deletion.

Why

The CMAP spec lists both options under Deprecated Options:

The following ConnectionPoolOptions are considered deprecated. They MUST NOT be implemented if they do not already exist in a driver, and they SHOULD be deprecated and removed from drivers that implement them as early as possible.

The C# driver implements them, so the spec direction is removal. A major version is the window for it.

Members in scope (14)

All are already marked [Obsolete("This property will be removed in a later release.")].

This is not dead code

Unlike the members removed under CSHARP-5996, these read all the way through to runtime behaviour. Chain at time of writing:

ConnectionString parses the waitQueueSize and waitQueueMultiple keywords.
ClusterBuilderExtensions feeds them into ConfigureConnectionPool(s => s.With(waitQueueSize: ...)), computing the size from the multiple when only the multiple is given.
ExclusiveConnectionPool initialises _waitQueueFreeSlots = settings.WaitQueueSize.
ExclusiveConnectionPool.Helpers.AcquireWaitQueueSlot() decrements that counter on every checkout and throws MongoWaitQueueFullException.ForConnectionPool(endPoint) when it reaches zero.

So there is an observable behaviour to decide about: today a pool with more waiters than waitQueueSize fails fast with MongoWaitQueueFullException. After removal, waiters would be bounded only by waitQueueTimeoutMS / CSOT.

Trap: the server-selection wait queue is coupled to this

MongoClientSettings.WaitQueueSize is obsolete, but ClusterSettings.MaxServerSelectionWaitQueueSize is not, and ClusterRegistry feeds the same value into both:

maxServerSelectionWaitQueueSize: clusterKey.WaitQueueSize,   // ClusterSettings - NOT obsolete
waitQueueSize:                   clusterKey.WaitQueueSize,   // ConnectionPoolSettings - obsolete

Removing MongoClientSettings.WaitQueueSize therefore also removes the only way to configure MaxServerSelectionWaitQueueSize from a MongoClient. That path has its own MongoWaitQueueFullException.ForServerSelection() throw in Cluster, which must keep working. The two need untangling before either can move.

Decisions needed

• What bounds the connection-pool wait queue after removal - nothing (rely on waitQueueTimeoutMS / CSOT), or an internal hard cap?
• How is MaxServerSelectionWaitQueueSize configured once the obsolete property that currently feeds it is gone? New non-obsolete setting, or a fixed default?
• Does MongoWaitQueueFullException stay public? It remains reachable via server selection, so it should, but the pool-side factory becomes unreachable.
• Connection-string handling: silently ignore waitQueueSize / waitQueueMultiple, or reject them? Note ssl was kept as a parsed-but-aliased keyword under CSHARP-5996 because the URI options spec requires it; these have no such requirement.
• CMAP ConnectionPoolCreated event currently reports both options; the spec marks those event fields optional and driver-dependent, so they should come out of the event payload too.

Notes

• Public API removal, so this is a breaking change and needs to land in a major release.
• Line numbers intentionally omitted; main has had a repo-wide dotnet format pass and they drift.