I have referenced the debug-log[] here and there on TWTalk, but it might have gotten overlooked by many. So, let me officially introduce it:
The debug-log[] filter will help you debug your filter expressions. All it does is output its input list to the console and pass along its input to the next filter step.
[tag[HelloThere]debug-log[]first[]]
The longer debug-log:ID[variableName] syntax will also display the content of the local variable with name variableName and use the heading ID for the table, so that the two tables output by e.g.
[tag[HelloThere]debug-log:initial[]sort[]debug-log:final[]]
are more easily differentiated.
Debug-log will show the difference between an empty list and a list with entries that are empty strings. This has often for me been a stumbling block when I forgot to add an is[blank] filter step, since <$log output={{{ <some filter expression> }}} /> cannot be used to differentiate between the two cases and will show an empty string even when there is no filter output. That’s probably a reason why I use debug-log[] more than $log or $action-log nowadays…
Also, it can be surprising how often filters are refreshed on a single button click. Where $action-log might output once, debug-log[] might output several tables to retrace how successive action widgets change the wiki state. I have used that successfully to rewrite code so that filters are called less often, putting complex filters into inner nesting widgets.
You can also call it using XXX[], so it stands out more in your source code (because you should remove it after debugging). This is an undocumented feature, though.
You can grab it as a plugin here: https://yaisog.tiddlyhost.com/
Thanks to @pmario for some great ideas during development.