1) The WG has already voted to use "textual port" instead of "character port", but the new draft has not yet been published.

2) It is false that "all the major Schemes" have implemented R6RS libraries. The definition of "major" is subjective and subject to change, but Chicken is a major Scheme by any standard, and has not implemented them. It's true that the R7RS library format is not quite a subset of R6RS's, but adding the R7RS features to an R6RS library implementation is expected to be trivial. The main R6RS feature omitted is phasing control, which is irrelevant to R7RS-small because it only allows syntax-rules macros. R7RS-large may wind up with explicit phasing controls or not.

3) It's true that the R7RS record system is incompatible with R6RS to the extent that they both use the name "define-record-type", but by the same token R6RS was incompatible with the de facto R5RS standard implemented by almost every Scheme (and trivially implementable on R6RS systems as well). R7RS simply reverted to the de facto standard rather than accepting the committee-designed R6RS system.

4) Parameters do not have a problem with converters: some implementations have a problem with converters. In any case, the problem only surfaces if the implementation supports parameter mutation (as distinct from binding), which is outside the scope of R7RS. I do not know what you mean by saying that "include" has a problem with hygiene.

5) Since R7RS does not define exactly what normalization means, it might or might not be case-sensitive, but if it is Unicode NFC or NFD, it would not be. Implementations and users are free to add their own double-dip comparison operators.

6) "Guard" was chosen for the sake of R6RS compatibility. You can't have it both ways. In any case, there are no reserved words in Scheme (although "quote", "quasiquote", "unquote", "unquote-splicing", and "import" are problematic to redefine).

7) So far, exactly one implementer has been negative about R7RS. Others have been silent, mildly positive, or positive. It would be difficult for the WG to require features that cause problems in implementation when we have not specified any features that have not yet been implemented.

Well, both Guile and Chibi are both meant to be embedded, but in different ways. The Guile 2.0 shared library is about ten times the size of the Chibi shared library (on 32-bit Linux); on the other hand, Guile 2.0 has a compiler, whereas Chibi is a fast bytecode interpreter. In general, Chibi optimizes for space: it doesn't provide multiple versions of procedures in the SRFI 1 list library, for example. Running Chibi (perhaps with some features compiled out) on an embedded chip makes sense; Guile is aimed at desktop and perhaps server applications.

I don't think there are any substantial errors in your summary, and I appreciate the writeup. If you want to add stuff, riff through the slides, it's faster.

Either I misspoke or someone misheard. "Environment enquiries" is a Common Lisp term for functions that return things from the environment such as wall-clock time, internal time in jiffies, the name and version of the implementation, the name of the hardware and OS the implementation is running on, the host name, the working directory, the Unix environment variables, the command-line arguments, and so on. Most of these things wound up in R7RS-small one way or another already, but I didn' t know that when I made the package list.

Not quite R7RS conformant yet, but that's definitely a goal. It's already R5RS conformant.

There is also a longer range plan to accept JavaScript, Lua, Go, and bash as source languages and translate them to Scheme.

The numbers in R5RS, R6RS, and R7RS are really superscripts: R5RS stands for "the Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme".

Personally I think that joke's pretty worn out, but the Working Group decided otherwise.

That's compatible, not incompatible.