I just ran into this problem (and I'm surprised that I haven't faced this problem during the many years I've been using [zl]): if I try to process a list that starts with a word that is an actual control message for [zl], instead of getting it processed, I get an error message. Of course, this is normal behaviour, and under most circumstances, it won't cause much trouble (after all, the chances for an ordinary max list to start with something like 'zlmaxsize' is not that high). However, the 'mode' keyword can be quite tricky in this sense.
To illustrate my problem, here's the following, tiny, almost-real-world-scenario example:
Now, let's assume that there is a big patch with a lot of things (pattr-ed objects, parameters in [route] objects etc.) called 'mode' (which is my current scenario, unfortunately), and let's assume that someone (me, in this case) needs to implement a couple of mechanisms to intelligently hassle with lists controlling these objects. As far as I see, my only solution would be to rename everything called 'mode' in my patches to something else, so that it wouldn't confuse [zl].
My question is: is there any other way to deal with this problem? For example, is there a way to force the [zl] family of objects to simply ignore the command messages sent to them?
Or any other trick?
Thanks in advance,