Detailed steps to reproduce the problem?

The CSOT specifications states the following:

If set, drivers MUST apply the timeoutMS option to the initial aggregate operation. Drivers MUST also apply the original timeoutMS value to each next call on the change stream but MUST NOT use it to derive a maxTimeMS field for getMore commands

One can verify that the Go Driver does not do this by running the "timeoutMS applies to full resume attempt in a next call" CSOT test.

Definition of done: what must be done to consider the task complete?

The Go Driver team should consider updating our internal test runner to apply timeouts given to cursor constructors to be applied iteratively, as that is the expectation. Another option is to update unified spec tests / unified spec runner generally to satisfy this behavior. It's unclear if any other drivers have this problem, however.

DRIVERS-2722 provides a long-term solution to this, but we should still consider a short-term solution. Most of the skipped tests are verifying other behavior and skipping them because we more maxTimeMS could hide bugs.