Current APIs exposes such future, but also submits transaction as side effect, but some use-cases shows, that having that future existing before transaction is submitted could potentially ease development of proper monitoring of transactions.

This is also true for TypedTransactions, where the body being executed only sees ReadOperations/WriteOperations, hence cannot actually submit the future – but it may want to hook further processing based on the outcome of the transaction. Hence the future should really be exposed from *Operations interface.