Transactional updates, available as an installation option in Leap, ensures
that each change to the system is captured and recorded within a transaction.
However, the limitation, compared to normal systems, is that system changes
cannot be tested for their practical effect until after a system reboot.
Afterward, if any problems are found, the transaction must rolled back, and the
change must be attempted again, after another reboot. Such a process is
particularly cumbersome if the outcome of a change would not be determined
until it would be tested in practice.

Proposed is a mechanism for opening a transaction, which would remain open
after the completion of the command opening it. Further commands would then
allow entry into the open transaction, either in read-only or read-write mode,
until the transaction is finally closed.

For example, one might consider consider the following command sequence:

1. sudo transactional-update begin
2. sudo transcational-update enter -w
  a. sudo zypper ins somepackage
  b. exit
3. sudo transactional-update enter
  a. cd ~/project
  b. make
  c. exit
4. sudo transactional-update commit

In the sequence, the user has requested that a new transaction be opened. It
will remain open even after the command completes. The user has then entered
the  environment of the transaction, with the ability to modify the system. The
tool creates a shell in the isolated environment, in which the user has
selected a package for installation, and then has exited. The transaction
remains open even after the shell closes. To test whether the system
modifications carry the desired effect, the user has entered again into the
transaction environment, but without the ability to modify the system. The user
has then attempted a build process, in the modified system environment, to
determine whether the system changes have had the desired effect. In this
environment, the installed package is available, though not on main system. The
user has finally exited the environment, and then committed the system changes.
(Alternatively, the user may have destroyed the transaction, if needed.)

After the transaction is committed, it represents the system state for the next
boot session.

In a normal system, a user may install packages or make other system changes,
and test the effects immediately. The user may then make further changes, or
reverse earlier ones, again, with immediate effect. The proposed enhancement
allows the same capability in an isolated environment, which is optionally
committed for the next boot cycle.

It is possible to achieve a comparable effect by simply adding a read-only
option to the tranactional-update command. This option could be combined with
the continue switch. However, explicit semantics for the use case is likely to
reduce the incidence of human error and ensure best practices.