We introduced Generic types in PyMongo 4.1 to enable applying a custom document_class that would be honored by many of our public APIs that return documents. A reason to do this was to enable the use of schemas, using TypedDict or dataclass, or some other interface definition.

However, the use of generics has come with significant downsides:

• The default top level objects such as MongoClient require a type parameter, such as client: MongoClient = MongoClient(), because we cannot give a default type.
• APIs that accept an optional codec_options such as Collection.with_options cannot honor the type of the codec_options parameter and instead use the parent type parameter.
• Many of our APIs have taken on the @overrides pattern, which clutters up the code base, and is actually rendered in our API docs.
• Much of our internal and external APIs have been forced to become Generic, which is an ongoing maintenance and consumer burden.
• We have had to work around the fact that namedtuple does not support the Generic mixin until Python 3.11, causing a messy workaround in our codebase.

I propose we do the following in PyMongo 5.0:

• Remove all uses of Generic. Most of our APIs that return documents will instead return MutableMapping[str, Any] which we can alias to a publicly documented Document type that shows up in the API docs.
• For places that explicitly return RawBSONDocument, return that explicitly.
• Add documentation and tests for the use of TypeGuard to enable schemas for PyMongo documents.
• Add full strict typing support, which will be much easier without generics.