You create a smart rule in the left pane. Something like this:
You choose what locations should be scanned for smart folders. In my case, I want the DB “res2”, and only smart groups in the root location, hence the “exclude subgroup”. Then you need some condition to be fulfilled for the script to act on. I chose to only select smart groups (which is already checked in Christian’s script anyway). Then you want this to act at a suitable moment; as Christian says, the ideal time is “before synchronization”, so that iOS devices always get updated “smart group mirrors”. To enter the script, press “edit script” and paste the above Apple Script in.
There are some caveats. Especially if the smart group looks for tags. For example, I have a smart group “untagged” that lists documents that are untagged. Those would be items in the inbox and groups that are explicitly excluded from tagging. However, the script replicates those files into a real group “untagged”, which, as created, is not excluded from tagging, and boom, from now on, there are by definition no more untagged items, as every items is either tagged otherwise or has the tag “untagged”. Creating those mirror folders, one could give them the “exclude from tagging” attribute. I’m not sure how to do that in AppleScript.
Another issue is that replication into these mirror folders is purely additive. So an item that was part of a smart group at some point, but no longer is because it now no longer fulfills the condition for the smartgroup, will remain there. So technically, every time the smart rule is executed, the existing mirror folders would have to be deleted first, and then re-written. Not sure if that’s what Christian means by
We add only additional replicants to the mirror, it's up to the user to move all instances of undesired items to the trash
With many smart groups and/or many items in them, this could be rather taxing on the sync process, and the trash will be filled with a zillion items, making it hard to monitor the items that you deliberately trashed.
Furthermore, if one has smart groups scattered throughout the DB hierarchy, you suddenly get the DB cluttered with these mirror groups that look like regular groups and that can become a problem, especially if you’re done mirroring (you get rid of a smart group) and they are left hanging there. Deleting them can be a bit of a minefield as you might end up deleting a similar sounding real group. Again, one could automate this by the script deleting the mirror groups before replicating them from the smart group, but giving a script wide-ranging deletion rights feels worrisome.
If using this mechanism, I would use a convention to name smart groups in a unique way, say “my smart group --”, so that one can identify all mirror groups by, you guessed it, making a smart group showing all groups ending with " --". Those can then be summarily deleted without fear as long as you are sure that no normal groups have such a suffix. (Or, smart groups don’t have that suffix, but the script appends something automatically.)
In conclusion, mirroring smart groups is quite an endeavor, I apply it very selectively.