Nonce Increment Gaps After web3js Pending Transaction Drop

When a web3js sendTransaction remains pending, the library does not automatically increment the sender's nonce on retry. The precise goal is to identify a retry pattern that guarantees write-idempotency for signed transactions without requiring the developer to manually maintain a nonce counter that survives mempool eviction and chain reorganization.

If the original transaction mines successfully and a resend reuses the same nonce, the network rejects the duplicate, preventing unintended writes. However, if the pending transaction is dropped from the mempool before mining, the nonce does not advance, leaving a gap that subsequent transactions must offset. This gap can cause sequence errors or, if the developer resends without incrementing, silently duplicate the write once the original eventually confirms. EIP-1559's maxFeePerGas and maxPriorityFeePerGas do not influence nonce behavior, leaving retry safety dependent solely on nonce management.

How should a developer detect mempool eviction before resending? What nonce value should be used if the original transaction's status remains ambiguous? Can transaction receipt polling reliably prevent duplicate writes in all network conditions?