Purpose: to ensure that the “in-transaction” code does not get interrupted by other code (e.g., a response to a button click or timer) until it completes.
This would be used to update multiple Client-side variables, where all updates must be completed (or rolled back), to keep the App’s in-memory variables in a logically-consistent state.
The classical example, in an on-line game: transferring (simulated) funds, to debit one account and credit another. Things can get royally botched if any code sees the transaction variables in a half-completed state!
It should be possible for these “transactions” to nest cleanly.
Rationale
Currently, most code relies on the brevity of such (implicit) transactions to protect them from unexpected interlopers. However, when such transactions include server calls or database activity, they’re no longer brief. The resulting errors, being extremely timing-sensitive, are nearly impossible to reproduce. The aim here is to let the developers prevent such devilish situations in the first place.