(edit) - As I thought this through a little further.
While I would love to have access to a runtime debugger for business rules, a runtime debugger does not replace the sort of degugging info I need to write to a log. A runtime code debugger and a logger serve two different needs.
For logging, I personally think a far simpler and better solution would be to provide a pair of new api/BRApi.UserLog() functions The idea of a user log would be to provide us a place to write whatever debugging type info we need without any redacting. The user log would only be viewable by the user who invoked the logic, and auto-delete when the user logs out the last session they may have open. As such, the user log might persist for a day at most. If you need to be debugging logic that someone else needs to run, then use the existing ErrorLog that can have some reasonable redacting (by "reasonable", I mean far less redacted than is currently being done with 9.0). A UserLog needs to collect log info for the one or more sessions a user may have running at any given time, so it is possible to view the UserLog from another session the user has open. It might even be handy to have a button to access the user log placed next to the Task Activity button, so non-admins can easily access their user log without having access to System.
The vast of majority of debugging stuff I personally write to the ErrorLog is of no value much more than 5 minutes later and simply makes it harder to find the log entries that do belong in the ErrorLog. Some of my log entries will still need to go to the ErrorLog, but the vast majority would more rightfully belong in a UserLog. An added benefit of a UserLog is that the entries will already be filtered to that user and with no other fluff. The only downside of this possible UserLog solution would be if one forgot to turnoff debugging when done (not that we ever forget), it might take longer for us to notice, during which system performance would remain less than optimal.
Please don't let OS off with this approach. If you've ever used a debugger to troubleshoot code, you know the amount of time it saves vs having to physically type out BRApi.ErrorLog.LogMessage(si, $"Some Value is: {value}") to write every last variable to the log, then stop execution and read the log.
The very idea that code you had to write to "debug", you have to delete 5 min later is the very reason for the debugger. With that tool you never have to write the code that writes to the log in the first place. Huge productivity increase immediately. Run the code, follow execution flow, and observe the variable values in realtime, in the actual code. You'll almost never use the log for this again.
At a minimum, we should be using a live console and not the log for writing things that pertain to troubleshooting runtime execution.
I revised my suggestion slightly. Much of what I log to the ErrorLog would be a bit out of scope of a traditional runtime code debugger. I will capture multiple specific pieces of info/loop and output all of that into a single ErrorLog entry. A traditional runtime code debugger would allow me to step through the code one line at a time and look at any of the variables at that point in time to more readily see where and why a block of code is coming off the rails, or to assist in finding coding inefficiencies. As such, we need both a runtime code debugger and also have a means of logging whatever messages we see fit to a UserLog. The two serve different but complementary purposes.
