These issues might be related.
Although AFAICR I never resorted to that particular kludge myself, evidently in the time before user properties were invented it was relatively common practice for ambitious scripters to stash various types of non-script content (especially binary data, which tends to get horribly mangled if stored in fields) in object scripts - basically just for want of a better mechanism to attach arbitrary stuff to objects or contexts. For whatever reason old habits die hard, and some grizzled veterans persisted in the practice long after it became unnecessary - even though it was STRONGLY discouraged.
Basically SuperCard shouldn’t ever insert NULL bytes in your scripts all on its own, but it will happily do so if asked.
But just like in fields, binary data (especially if it contains characters < ASCII 32) typically won’t display legibly, so even scripts containing large blocks of binary data may appear empty if you try to edit them. The binary content itself may also get mangled if just unpacked for editing and then saved (even if you don’t touch it) because the interpreter sometimes tries to strip off what it views as garbage bytes at the beginning or end of a script (to work around an ancient bug that apparently sometimes added stray binary bytes to scripts during conversion from HyperCard stacks).
So short form: yes there really could be a NULL byte (and even a LOT more invisible data) in scripts (especially of old projects) if someone once decided to put it there, but this practice is VERY unsafe in SuperCard (so any script you find doing it should definitely be changed ASAP to store that data in a user prop instead). Likewise you also shouldn’t assume anything you find in a script that starts with a NULL is really just one byte long, or that you can reliably clear binary data out of a script by selecting all and deleting in the Script Editor (because binary data may not be 100% editable), and you should use a ’set’ command to clear it instead to be sure. Nor for that matter can you assume all such stored non-script data will contain one or more NULLs (although the potential occurrence of NULLs in it is probably what once led someone to stash it there in the first place).
Thus your strategy for avoiding specifically any scripts that contain NULL is basically sound, but you should be aware that NULL is not the only troublesome byte potentially lurking in such ‘abused’ object scripts. So if you’re really trying to skip scripts with non-script data in them (not just NULLs) then you might instead have to loop thru each script character-by-character looking for obviously non-script bytes (i.e., < ASCII 32). Of course even this isn’t a 100% reliable indicator of script vs. non-script content, but it should at least catch the most problematic content.
Does that help any?
-Mark