Thanks for your comments!
The build script will write comments in generated_dictionary.inf, noting any collisions. In some cases it may be okay, e.g. if a verb has the same checksum as a noun or a preposition, that will never be a problem, or if synonyms for two objects that will never be in scope at the same time have the same checksum, that’s not a problem.
If you do find that there’s a collision that will cause problems, you can consider renaming an object. Maybe a stone can be named a rock, etc. If you aren’t interested in making compromises, this just isn’t the system you’re looking for.
I can’t easily run a test on all Infocom games, as I’d need to go through the dictionary of each game and figure out what characters are missing for words that have been cut off.
I have tried to do this for Zork I (690 words) and PunyInform Adventure (740 words), and at least for these games, I could find factors causing no collisions.
I also tried this for Trinity (2100+ words), and got something like 15 words with non-unique checksums. That’s a much bigger game than what NAIL is meant for though.
There’s a lot that people take for granted that isn’t supported by NAIL. You can’t take a library that’s been heavily optimized for size, such as PunyInform, reduce the size by 50%, and still have support for everything that’s nice to have.
Note that NAIL isn’t meant to supersede PunyInform. It’s a lot cruder, but may be good enough for some kinds of games, where both authors and players accept cutting some corners in order to get a small enough game.
I may have a look at this particular feature, to see if it can be implemented cheaply enough. If it’s 50 bytes, then sure. If it’s 500 bytes, it’s not happening.