As noted in a comment in this BT's Base_redirect implementation, original code
does raise when abort_transaction is true.
Not raising in this implementation means that this script will return to caller,
while it never does on original code.
Also, to add insult to injury, this utterly bogus implementation interferes with
transaction boundaries. So suddenly, a single publication spans over 2
transactions, which can lead to:
- ZODB Connection sharing, breaking transaction isolation
- the second transaction implicitly created by this abort (actually, by the next
transactional connector registration to transaction) may be committed,
in which case anything done after Base_redirect returns will be
persistently committed, against caller's explicitly specified intent, and against
all developer expectations.

NEVER TOUCH TRANSACTION ! Only CMFActivity and unittests are allowed
this level of access (and CMFActivity should be modified out of this exceptional
state).