Because we can

Sort of. If the installer supports transactions, then it can proceed to install within a transaction, and on failure, a single call to RollbackTransaction() will clean up all the changes it made. In other words, installers will need a lot less error handling logic.

There is no way to uninstall a successfully installed package in this way - as soon as it's committed, it's committed.

It is possible, although you should be extremely careful doing this, to initiate a legacy install within a transaction, and commit or rollback the transaction yourself, depending on how satisfied you are with the results. This should guarantee no file or registry changes will remain if you rollback. But please be careful - as discussed in a previous post, there are caveats here. What if the installer used transactions itself? Your rollback would no longer roll back everything in the way you might expect - they may already be committed, or the installer may switch out of your transaction and proceed with the install, precluding you from rolling it back.

Geoff: the scope of the transaction is perfectly defined :)

The issue is that Transactional NTFS was always intended to be primarily a developer feature, to be used by developers in applications. There are lots of hazards in modifying behavior for existing applications in any case, transactions perhaps moreso. While there are benefits in using transactions to transactionally-unaware applications, that was never the primary focus of this technology: and for that reason, applications, rather than system administrators, are in charge of their transactional state.

So to define the scope of a transaction (I'm probably missing something, but here goes):
- A transaction within a thread will remain active until SetCurrentTransaction() is called. If the transaction commits or rolls back, it is still active, until SetCurrentTransaction() is called.
- If a thread attempts to spawn another process, and specifies a bInheritHandles value of TRUE in CreateProcess, and the transaction was marked for inheritance, the child process will commence execution as part of the same transaction. But, as above, this only continues until those threads call SetCurrentTransaction(). Note that it will also remain in the context of the transaction if the parent process commits or aborts the transaction - this is another source of Seriously Bad Consequences.