To add to the conversation of Election scheduler and prioritization revamp I feel a separate topic on what can be done to avoid keeping the network at saturation at negligible costs would be good to have.
Some sort of account-level burst control is required or the network will be at saturation at all times, which is what Colin said, and it doesn't sound bad when the majority of network capacity will be real transactions, but right now, with 2-3 CPS being real, even with bandwidth limits, the remaining 80% will be dust, deprioritized, but still here.
Maybe we can use POW as a defense mechanism than a priority mechanism.
If (balance * time_since_use) < (Mean SPAM Number)
The difference with every moving decimal needs an exponentially scaling POW to validate the transaction or it is dropped immediately.
Spam Number could be a parameter each node operator can declare, It is manual, but a decentralized way to defend from dust txns.
Also, time_since_use minimum is declared as 5 seconds for further burst control. This cooldown to validate a send will not affect any human user or large-scale services imo.
There should be an upper limit to how much the PRs can set the spam number to so that the bad actor cannot disguise as PR and raise the network minimum acceptable transaction. For simplicity let us assume this number comes to 0.0001 (b= 0.00002, t= 5) as the max setting allowed.
Example: The mean spam number of PRs is 0.00001, with every moving decimal to this, the dust spam needs POW^(10)^X+1, with X=0, 1, 2 ...
Since (balance * time_since_use) adjusts in value and combined with burst control in place the hopping attack vector where dust is left behind can also be mitigated, but finding this number can get complex for a manual slider. If burst cooldown for 5 is approved, t= 5 will be constant and that would make it easy for a consensus.
With Equihash in place, we don't have to worry about POW being easy as well.