Today, when a dapp calls eth_sendTransaction, the parameters are sent up to the signer, and the app is called back once, with the resulting transaction hash.
This is a great way to allow a dapp to track the progress of a signed transaction, assuming that transaction is static and not mutable.
Recent transaction backlogs have forced us at MetaMask to add a button on long-pending transanctions to "Retry with higher gas price", but if a dapp or service was tracking the signed transaction by hash, it has no way of discovering that this transaction was ever resubmitted successfully.
This is only a problem for apps that submit a transaction, and continue tracking that specific transaction hash until it is mined, but for dapps with that problem, one solution could be to add a new method, maybe called eth_sendMutableTransaction, which calls back not with a transaction hash, but maybe with a transaction identifier, which can then be used to subscribe to various changes in status, including being mined, being resubmitted with a revision, or being rejected.
In addition to allowing users to resubmit transactions with a higher gas price, this could also help facilitate a more advanced transaction submission algorithm, where transactions are initially broadcast with lower gas prices, and gradually re-submitted with higher gas prices until hitting the user's upper bid limit. This would allow the discovery of the lower bounds of the gas price market, bringing down gas prices both for users bidding in this manner, and for users who are estimating fair gas prices based on historic gas prices.
Since this transaction identifier would be stored client-side, it might not be useful for dapps that want to track a transaction's progress on a backend, once the user's browser window was closed, but as long as that user was logged in, presumably that site could re-query the transaction by identifier via the web3 API.
Since this is a personal, local signer method, it might not belong on the global eth_ namespace. Instead, I'm in favor of generally moving signer-centric methods into their own namespace, maybe wallet_.
If that were the agreed way, this method could be made possible with wallet_sendMutableTransaction.
Would we still need this if we had a more standardized and flexible txpool methods that let us query the pending transaction pool with transaction hashes?