A while ago, while we were working toward the current beta specification, @scottdixon pointed out that the transfer-ID timeout is an odd item because it brings a rather arbitrarily-chosen default parameter into the specification while also requiring users to tune it per use case. At the time we didn’t have any better ideas so we left it as-is. I think I do have a better idea now.
In Cyphal/CAN, everything stays as-is. In all other transports, which happen to be using very wide 64-bits transfer-ID counters, we set the initial transfer ID value randomly instead of zero initialization. The random values should differ across power cycles. For transfer senders, this is the only change: random 64-bit integers instead of zeros.
For transfer receivers, we amend section 4.1.4.2 such that transfers whose transfer-IDs are separated by more than one million counts are also considered unique (this also covers the 64-bit wraparound). The probability of randomly picking a new 64-bit value that falls into a given million-count span is about one in 18 trillion. For backward compatibility, the transfer-ID timeout rule stays as well, but in the implementation libraries the timeout will be fixed initially at 2 seconds (as advised in the specification) and it will no longer be user-configurable (simpler API). Eventually, we might consider increasing this value in implementations to ~1 minute.
This is also why all new transport specs should prefer 64-bit transfer-ID values.
(FYI this is not the big announcement I promised a few days ago, just a quick remark)