I'd like to start this thread off with a bug and fix for an old favorite, Blazin' Forth.
The C64 has a vector for the system IRQ at address $314-$315 so software can "patch in" it's own IRQ.
Blazin' Forth uses this for sound and music words. It saves the old address in a variable named SYSIRQ. The new IRQ performs an indirect jump to the old IRQ through SYSIRQ. Blazin' Forth, like any decent ITC Forth for the C64, checks if the code field of a new name will cross a page boundary. If it will, the dictionary is padded with one byte prior to creating the header. Scott Ballantyne included the source for the system loader so someone could modify it ( after making a backup ), forget THRU, and reload the system.
Although no word will have a code field that crosses a page boundary, it is possible for part of the parameter field to cross a page boundary. In an ITC Forth, this is harmless unless the parameter field is used for an indirect jump address.
This is where the bug comes in. If the system is altered and rebuilt, there is a possibility that the one cell parameter field of SYSIRQ will cross a page boundary.
For the bug fix there is a word in Blazin' Forth, " , that will create a counted string in the PAD. It can be used to avoid this bug.
Replace

with this

Note that VIEW? , the variable that determines if a view field is created, is off during the loading of the system.