3b. Sending an equivalent command for the second attempt? in the Retryable Reads spec allows drivers to do one of two things when retrying a command:

• If the wire version changes between retry attempts, the driver can recreate the command document according to the wire version of the server selected for the retry attempt. Any error in doing so should result in skipping the retry attempt and raising the original error.

• If the driver doesn't recreate command documents, it can raise an error whenever the wire version dips between retry attempts.

The Retryable Writes spec has no such language. At the time the spec was written, the feature was only supported on a single server version and we only considered the scenario where the server selected for a retry attempt did not support retryable writes at all (e.g. pre-3.6). To quote the spec:

If the driver cannot select a server for the retry attempt or the selected server does not support retryable writes, retrying is not possible and drivers MUST raise the original retryable error. In both cases, the caller is able to infer that an attempt was made.

Since the time the spec was written, supported write commands have had the following API changes (new options):

• insert: comment in 4.4+
• update: hint in 4.2+ and comment in 4.4+
• delete: hint and comment in 4.4+
• findAndModify: hint and comment in 4.4+

If we can verify that 3.6+ servers raise always raise errors for unsupported options (thanks to strict validation), then perhaps no spec and driver changes are needed; however, it'd still be wise to explicitly discuss this in the spec and explain that drivers can rely on that behavior.

Alternatively, we may want to adopt language similar to what is found in the Retryable Reads spec, which may entail driver changes.