If the config file is modified on disk while the iterator code is
walking over the data, the profile code will re-read the file, build a
new node tree, and next time the iterator is used, it will again look
up the sequence of names it's using, and walk forward to the Nth
entry under that name, when it kept track that it was on the Nth entry
in the old version of the file.

More sensible, probably, would be to keep a handle on the old data, so
that we don't return a mix of new data and old.  A new ref count, a
new mutex, and a new level of indirection can do this.  Sounds simple
enough, but consider too how this might interact with a program that
is itself trying to make modifications.  Contemplate the horror of
multiple threads trying to iterate and make modifications to the same
data at once.  Then run screaming into the night, while race
conditions hiss and growl as they claw their way out of the pit,
sniffing at the air to catch the scent of the dangling pointers you
leave behind as... oh, sorry.

Should a modification attempt fail if the library knows that the
on-disk data has been modified?  Should we just ignore the disk
changes and overwrite it?  Etc.

Ken