Now that mIRC is fully unicode this is no longer a problem ($chr(160) *is* the unicode codepoint for NON BREAKING SPACE)
In fact, $chr(160) can finally be recommended as a viable solution since it will work across all fonts. In 6.35 and prior versions, $chr(160) was not guaranteed to be an empty space for many fonts, and should not have been used (although lots of scripters misused it). Now that mIRC is using the Unicode codepoint for a non breaking space, this character is the same glyph universally.
Of course, this gets you "spacing", but is a) not compatible with non-Unicode clients and b) does not handle tokenization, ie. it is not a true space, as mentioned above. If you use this character to space text you would confuse scripts that tokenize by spaces. Perhaps $gettok should be able to take a list of token delimiters rather than a single one. Until tokenization routines can handle this, it's still not a great alternative to true multiple space support via a construct or something.
