[EDIT: Actually wrote something]

Currently, there are three ways to broadcast a tx: _async, _sync, and _commit.
The first returns immediately (with no result), the second returns after CheckTx (and with the result of the CheckTx), and the third returns after the tx is included in a block (and with the result of both CheckTx and DeliverTx).

Using _commit is mostly for development stages. The more common usage is going to be firing off txs via _async or _sync, and checking up on the actual result of the DeliverTx later.

This calls into question a few issues. First, a user needs to be able to monitor the status of a transaction - is it still in the mempool, did it recently become invalid (and hence dropped from the mempool), or has it been committed? Second, if it's been committed, or even become invalid, we need to be able to fetch the result.

Seems in both cases we should have a way to query txs by their hash, which by the expected "only-once" semantics of ABCI apps, should be a unique indicator for every tx. The result of query should include the block it was committed in, the tx bytes themselves, and the ABCI response data. Alternatively we can split that into two calls, one for the tx-bytes and one for the response (aka receipt). A tx that was committed should be queryable forever; a tx that was invalidated should return why it was invalidated (the replay CheckTx result) for say up to 12 hours (configurable I guess).

Note this means we have to save the response data, which we currently do not do! This can go in the blockstore when blocks are saved, but shouldn't be included in the block itself. It is additional data that is stored for convenience so we don't have to go recompute the whole blockchain with every query.