Observing that filenames in the 'l' listing have the / slashes translated to \ format, but the subdir/ entry still has the slash as forward. Keeping a slash at the tail of a subdir entry is useful, identifying it as different from a zero size file.
This is actually what is being returned by libzip. mIRC is not making any changes to the results. I could make mIRC fix the slashes but then it wouldn't be what is in the zip file. On the other hand, not fixing the slashes means that scripts have to deal with both \ and / ... This change will be in the next beta.
it would be useful to have a parameter to alter the default compression level
I would rather avoid adding more complexity. At today's internet speeds, I would generally opt for faster compression. Especially with $zip(), which does not support multiple CPU threads, etc., so it is going to be relatively slow anyway. I have set $zip() to use the fastest compression level by default.
Not sure if it's intentional that in this case 'l' with N=0 reports 0
It is, the zip file is failed at the very earliest stage if it contains "..", so all zip-related features will see a failure. Another option is to handle this like 7zip; In some contexts, 7zip will convert ".." to underscores, in other contexts it will remove "..\" completely from the path (which can result in an empty file/folder name if all it contains is "..\..\..\"), and so on. I could make $zip() do all of this but if a zip file contains a zip exploit, I would rather just fail it consistently across all $zip() features.
