If I am running a new instance of WT (i.e. no existing data) and I start a transaction at timestamp 10 (but do not commit it yet), I would expect all_durable to be 9. However, it is instead reported to be 10.

The all_durable timestamp is calculated here. This behavior appears to be because since we do not yet have a durable timestamp, ts is set to 0. Thus, the condition

if (tmpts != 0 && (ts == 0 || --tmpts < ts))

short-circuits at the condition ts == 0 and never reaches the --tmpts.

For completeness, I will note that this scenario is distinct from the case of starting up with existing data. Say I commit a transaction at timestamp 10 and take a stable checkpoint at 10 as well. Then if I restart WT and open (but do not yet commit) a transaction at 20, I would expect all_durable to be 10 (not 19). I haven't actually tested what the current behavior here is; referring back to the above linked code, I believe it depends on whether txn_global->durable_timestamp has been set yet by this point.

I will also note that we believe this does not currently manifest as an actual bug in MongoDB. We theorize in the worst case, a "replica set initiate" or "new primary" oplog entry could become visible earlier than intended. This should be benign because there is not any "real" data associated with such an oplog entry.