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).
No, we are simply admitting that the port abstraction is a leaky one and that not all operations work on all ports. As things stand, Chibi implements char-ready? as u8-ready? and does not attempt to find out if the trailing bytes of a multi-byte UTF-8 character are available. Chibi does not have a general I/O multiplexer (which would be difficult to fit in with its use case as an embedded Scheme) and simply calls poll() on the single relevant fd.
If I add non-trivial features to this SRFI, the set of available implementations drops from "all R6RS systems" to "none". I am not eager for that to happen. I will add flush as an optional argument to the make-custom-port procedures with a warning that it may not be called on all systems.
I am considering adding the MIT Scheme feature of custom operations: a custom port is defined with an optional alist mapping operation names (arbitrary symbols) to procedures, and then there is a user-level (port-operation port name) that pulls procedures out of the alist. But even that may not provide enough bang for the buck, as it has to be specified in such a way that it may return #f, just like flush.