> I'm not disagreeing with you here, but your argument is about the
> utility of u8-ready? char-ready? themselves.
>
> Of course, if I'm writing a large program talking to character devices,
> network pipes, and files all at once, I will use an infrastructure
> better suited for polling many channels at once.   And I admit that
> while I have faithfully implemented {u8,char}-ready? in my own
> implementation and tested them, I have written no programs that make
> effective use of them.
>
> If we are to honor R7RS, with u8-ready? and char-ready?  I think we are
> obligated to support their implementation in custom ports as well,
> otherwise, we are declaring those procedures deprecated and useless
> (which /may/ be a valid decision).

Deprecating them may be a valid decision. IMHO, the `port-ready?`
procedures in various programming languages are generally a design
mistake. Often they seem to have put in to serve a particular use case
(waiting for a terminal keystroke, or lookahead in parsers) but are
problematic as general-purpose abstractions.

The language should probably have one central (wait ...) procedure that
waits for one or more things of assorted kinds. That facility could be
extensible somehow to cover user-defined port or data types. It would be
quite complex to specify, and a reliable specification might have to
depend on environmental factors like OS threads vs green threads vs
single-threaded, implementation of continuations, etc. Marc has a ton of
pertinent experience, whereas I shouldn't be allowed to touch a spec on
the topic :)