Today, the only way to wrap transactional code in a "Try/Catch"-esque manner is by using
"If codeunit.run() then"

This has a couple of weird ancient quirks that result in a mix of worse performance, worse readability and more footguns for new AL developers.

Problems:
1. You cannot have an active transaction going before invoking it. There is no good technical reason for this limitation.
2. when it returns true, it has an implicit commit. This is a common footgun, even BC developers with 10+ years experience get surprised by that one.
3. It can only handle one record parameter.
4. OnRun is a "magic" trigger requiring a new codeunit, every time one is needed.

Suggestion:
Expand the TryFunction with a parameter "AllowTransactions" (bool), with default value false for backwards compatibility like this:

[TryFunction(true)]
ThisFunctionIsAMoreErgonomicCodeunitRunTrigger(Param1: Text; Param2: Integer)

If you leave out the old limitations described above in 1) and 2), but leave the forced rollback upon error it would behave like a more intuitive and more flexible Codeunit.Run() construct.

Side bonus: There has been suggestions in the community to add Rollback() to AL. This would be solved indirectly with this construct as one could do:
[TryFunction(true)]
Rollback()
begin
Error('');
end;

as it would be invokeable from inside a transaction, as opposed to "If Codeunit.Run() then"