A rule is said to be stable if its guards remain stably true before the output fires. An unstable rule can have its guards momentarily evaluate true before the output fires. In the simulation this translates into an event being enqueued, and dequeued (or altered) before it fires. The simulator uses the policy set by unstable to choose an action when there is an instability. For any policy except ignore, the simulator prints:
WARNING: unstable `$1'+/-
>> cause: `$2' (val:$3)
This means that the new transition on node $2 to value $3, caused the guard for rule $1 + or - to become false while the event was still scheduled.
WARNING: weak-unstable `$1'+/-
just means that the instability was caused by the guard expression becoming X, meaning that there may be an instability. In the unstable-unknown (default) mode, the previous pending event on $1 will be over-written to become X, which is a conservative model of what could potentially happen in a real circuit. The alternative is to use the unstable-dequeue policy, which simply dequeues the unstable rule from firing.
Rules are interfering if the pull-up and pull-down rules can both fire at the same time, i.e. they form a short path between Vdd and GND.
WARNING: interference `$1'
>> cause: `$2' (val:$3)
reports the latest rule that turned on to cause interference. Usually this means that there is an error in the production rules. Take a look at fanin-get $1 to see which subexpressions in the rules are on.
A weak-interference occurs when an X is fighting a 1 or X pull. This can frequently occur transiently during reset, when nodes are still coming into known values. mode reset can be used to ignore these, for example, during the reset phase.