This happens in a very specific situation: links created from list filters to be shown into filters form.
Together with the filter I click, list machinery exports also every other page variable, so the list doesn't forget all other filters, but just adds the one I have clicked. In this situation, if we export empty variables, xowiki initialization puts the extra brackets into play.
Another situation where this happens is when we come back to a template::list:: page initialized in xowiki from a url created by "ad_return_url". This proc exports every variable, including empty ones, so xowiki initialization will treat them as "{}".
Real example: I have a list where I filter my entries by title. This list is created by template::list into a "xowiki initialized" page. In the list I have "edit" action, and I create the url so that when I finish editing, I am taken back to the list I was looking before. This url is created by ad_return_url. Leaving empty the "title" textfield of my form makes so that when I come back, textfield contains a "{}", and my entries are not shown because they don't match this pattern.
The solution for me was replacing "ad_return_url" with "export_vars -base [ad_conn url] -entire_form -no_empty" that basically is the same thing, but without exporting empty vars.
Xowiki's approach is probably more correct, because we could have mandatory variables that are just good as empty strings, and removing them could cause failures by the page contract. It would be just great if they could stay the empty string and don't turn "{}", otherwise template:: machinery and xowiki's become harder to mix.
