When creating an iterator, the user can pass a set of flags that indicate their requirements for the iterator:

INVALIDATE_NONE                         0x0
INVALIDATE_ONRESIZE                  0xFFFF
INVALIDATE_ONKEYADD              0xFFFF0000 
INVALIDATE_ONKEYDELETE       0xFFFF00000000
INVALIDATE_ONVALUECHANGE 0xFFFF000000000000
INVALIDATE_ALL           0XFFFFFFFFFFFFFFFF

Each hash will contain a version number, a simple monotonic counter.

The flags will control which actions will update that counter. 

Each iterator will take a copy of the counter at the point of its creation;
and compare that copy with the counter in the hash each time it is called.

If they are different, it will free the iterator storage and raise an exception.

Nice idea -- economical -- but it would mean that either:

    the flags would need to be applied to the hash not the iterator and therefore all iterators for a given hash would have the same attributes.
    
or

    each of the monitored operations would have to update the versions in all current iterators.
    Even for modest numbers of iterators, the looping, indirections and locking involved would impose a substantial hit on the performance of the affected operations.

or

    the hash would need separate counts for resizes, adds, deletes and value changes :(
    
    Could they be safetly combined into a single count? (eg. union{ U64 version; struct { U16 updates, adds, deletes, resizes; } })
    With the flags specifying a mask applied to the U64 version to detect the changes?
    What are the odds of an iterator being called when exactly 2**16 disallowed changes (* the number of disallowed types of change) have occurred?
        Minimal! The iterator would have to be called the first time after creation, when exactly 65536 (or some exact multiple thereof) changes of the disallowed type had been made; and not once before.
        And if more than one disallowed type the odds are 2^16 (*2^16) slimmer. 
        And in the unlikely event that occurred; the iterator would be invalidated then next time it was called unless it also happened after an exactly multiple of 65536 changes have been made. 
        As close to impossible as I need!.
        
Conclusion:
    The version counter will not be a simple monotonic counter of all changes, but rather a 64-bit value consisting of 4 x 16-bit unsigned, rollover counters. 
    The per iteration check consists of masking the iterator copy and comparing against a masked view of the hash version.