Copy/pasted from GitHub for more discussion:
Per the recent spam, it seems like one issue that causes compounding problems is nodes that send long chains of unconfirmed transactions that need to get resolved, but some of those transactions get lost in the backlog, or end up as forks that need (and struggle) to get resolved
Would it make sense to change the default node behavior to only send if "previous" is locally confirmed, unless overridden by a "force" option? That might help shrink backlogs, allow for easier fork resolution, and prevent potential work re-work
Copy/pasting bbedward's rebuttal:
I disagree with this idea, queuing transactions is something that should be handled by the node/protocol (as it currently is). It would be atypical to have this queuing be implemented at the application level and would complicate Nano integrations. With traditional blockchains you queue as many transactions as you want in the mempool.
Copy/pasting my response:
This wouldn't remove queuing from the protocol - it would only change the default node behavior to local queuing if "previous" is unconfirmed (to slow down the publishing of extended unconfirmed transaction chains, unless forced)
What's the benefit to publishing transactions if the required "previous" is unconfirmed and may get rolled back? Seems like you'd have to wait the same amount of time in either case, except default local queuing reduces potential forks (more costly for the network to resolve) and the compounding effect of a network backlog/slowdown. If "previous" is locally confirmed, then nothing changes anyways