WARNING:
    --------
    This section details some internal implementation details of
    iffparse.library which may help you to understand it better.  Use of
    the following information to do "clever" things in an application is
    forbidden and unsupportable.  Don't even think about it.

It turns out that storedproperties, collectionitems, and entry and exit
handlers are all implemented using lcis.  for example, when you call
findprop(), you are actually calling a front-end to findlocalitem().  the
mysterious identification value (which has heretofore never been
discussed) is a value which permits you to differentiate between LCIs
having the same type and ID.

For instance, suppose you called propchunk(), asking it to store an ilbm
bmhd.  propchunk() will install an entry handler in the form of an lci,
having type equal to `ILBM', ID equal to `BMHD', and an identification
value of IFFLCI_ENTRYHANDLER.

When an ilbm bmhd is encountered, the entry handler is called, and it
creates and stores another lci having type equal to `ilbm', id equal to
`BMHD' and an identification value of IFFLCI_PROP.

Thus, when you call findprop(), it merely calls findlocalitem() with your
type and ID, and supplies IFFLCI_PROP for the identification value.

Therefore, handlers, storedproperties, collectionitems and your own custom
lcis can never be confused with each other, since they all have unique
identification values.  Since they are all handled (and searched for) in
the same way, they all "override" each other in a consistent way. Just as
StoredProperties higher in the context stack will be found and returned
before identical ones in lower contexts, so will chunk handlers be found
and invoked before ones lower on the context stack (recall
findlocalitem()'s search procedure).

This means you can temporarily override a chunk handler by installing an
identical handler in a higher context.  The handler will persist until the
context in which it is stored expires, after which, the original one
regains scope.