Sorry, I still can't get behind a universal UI event abstraction.

> I originally did that.  The thing is that there turns out to be a shared
> core of event types and properties between terminals and canvases, and
> I'd like to keep UI libraries as consistent as possible in terms of the
> event types and properties they use.

The classic terminal and canvas events are an easy subset of the full
problem. It gets much more difficult once you get in to the modern stuff
I listed.

And if we're dealing with the easy stuff, why not just hand-roll a
separate terminal API and a canvas API?

If they use the same field names, that's nice. But I suspect there would
be leaks in a universal abstraction between GUI and terminal.

> So I'm suggesting providing a SRFI with the event-poll procedure (which
> now returns a plist) and explanations of standard keys to avoid
> unnecessary drift, while events remain completely extensible.

I don't understand event-poll. How and why would one procedure return
events from many sources?

> (Why poll?  Because I think a polling loop analogous to `read` is much
> easier to user than exception-based delivery.)

Strongly agreed. Exceptions should be for stuff that isn't supposed to
happen. (Continuable conditions may be an exception to that rule.)