SF Ballot Counting Keyhole; call for non-GUI keyholes

I've moved some of my Keyholes material into my general talk on improving
software quality (see http://www.aristeia.com/betterSoftware_frames.html),
and I recently got the following comment on the TKP part of that talk:

  Numerous people commented that they got the idea in a couple of slides
  and that more slides on the subject was overkill.  Consider finding
  keyholes on other levels of development than the GUI.  (design,
  architecture, testability, modifiability, etc.)

This is an excellent idea.  Today I heard on the radio about how a software
limitation caused problems in San Francisco in Tuesday's election, and
since that sounded like a non-GUI keyhole, I looked it up on the web.  This
is taken from http://www.compliancepipeline.com/52200270:

  the problem stemmed from a safeguard in the software that converts
  optical scans of ballot results into data that the computer system uses
  to calculate winners. The conversion software shutdown when the amount of
  data entering the system had reached a level set by the vendor.
  
  The safeguard was to prevent the system from exceeding its capacity. But
  after the breakdown, ESS determined the limitation was no longer
  necessary

How nice: a possibly justifiable keyhole had become a vestigial keyhole of
disaster.  Check the above URL for the full story.

In the meantime, if you come across non-GUI keyhole examples of the kind
suggested above, please send them to me or post them to this mailing list.
I continue to believe that GUI keyholes are just a manifestation of a more
widespread conceptual problem, but additional examples will help me make
the case more successfully.

Thanks,

Scott

PS - I've been toying with buying a Mac lately.  Man, you gotta love
keyholes to put up with the Apple web site...