Just my two cent - I would have many very good applications for that feature:

• Keep option lists identical over different logbooks.
• Keep option lists identical over different applications.
• Create option lists from a database - that allows to use the options in many applications and in the database; e.g. a list of systems with a failure database, but failure reports in the regular ELOG.
• Export extendable option lists to other applications:
  • Inform administrator about options that have been newly added to a logbook for a review.
  • Provide option lists as menu buttons in these applications.
  • Prevent other applications to submit elog entries with illegal option choices.
• Import extendable option lists from other applications (at least after next elogd restart, if no "update option list" URL/command is provided for elogd).

We recently went through the process of renaming a "system list" in several logbooks, to make it consistent over several facilities. If the "on-call service" is called "radio frequency", but the "system" is called "RF", then searching the logbook can become difficult. It was painful: half a dozen applications had to be adapted at the same time the lists were updated, because they had features to create a failure report to ELOG - assuming specific "system" names.

So I'm in favour of putting that high up in the wishlist :-)