Anyway everything you suggested can be done already by simply using the /DEBUG -i option, excluding the ON DEBUG event, which would be able to be caught by muiltiple handlers, but really how many scripts handle debug info anyway.
1) The -i option requires an identifier and its return value is used as the debug line being logged. What if I dont want to return anything? Return null maybe, but will that work?
2) Using multiple handlers is fine, but, can you write to the debug log yourself? I couldnt. Using a @window would work for manipulation, but it just seems that if /debug offers multiple output methods by utilizing whats already internally built in, hash tables could also be utilized.
3) The item names, got me there, but what about using the servername + date/timestamp via $encode() perhaps.
Debug might not be widely used. But perhaps it might be if it was extended to allow more control/flexibility. /debug just seems to feel like when you do try to utilize the data it provides, you usually end up having to script more than feels necessary to use it effectively. I think an event for just this reason would be perfect.
