SRFI needs to die a painful death.

    SRFI 1 -- enough functions to make lists useable
    SRFI 25 -- multidimensional arrays
    SRFI 28 -- format strings
    SRFI 30 -- nested multiline comments
    SRFI 34 -- exception handling
    SRFI 41 -- streams
    SRFI 43 -- make vectors usable
    SRFI 47 -- add arrays
    SRFI 50 -- C FFI
    SRFI 57 -- records
    SRFI 69 -- hash tables
    SRFI 79 -- primitive (low-level) IO calls
    SRFI 89 -- optional args and named params
    SRFI 111 -- Boxes
    SRFI 121 -- Generators
    SRFI 169 -- underscores in numbers
    SRFI 180 -- JSON (not approved as final version until 2020....)

The convention of using SRFI numbers is very anti-user. Those names are much easier to read and understand. It's very hard to discover stuff.

Let's say I'm not new to programming, but I'm new to scheme and choose the very popular chicken and find myself wanting hash tables. Are they built-in or an egg? Well, searching around the manual gives the following:

http://wiki.call-cc.org/man/5/The%20User%27s%20Manual

The manual has a clear "extensions to the standard" page, but that has a hard assumption that you know what the standard says (you probably don't). If you assume hash tables are in the r5rs spec, you are about to waste a ton of time finding out that they aren't there.

http://wiki.call-cc.org/man/5/Extensions%20to%20the%20standa...

When you finally come back to the "Extensions to the Standard" page, you get this:

    compile
    chicken, compiling, library, eval, extras, regex, srfi-0, srfi-2, srfi-4, srfi-6, srfi-8, srfi-9, srfi-10, srfi-11, srfi-12, srfi-15, srfi-16, srfi-17, srfi-23, srfi-26, srfi-28, srfi-30, srfi-31, srfi-39, srfi-55, srfi-61, srfi-62
    load
    chicken, extras, srfi-0, srfi-2, srfi-6, srfi-8, srfi-9, srfi-10, srfi-12, srfi-17, srfi-23, srfi-28, srfi-30, srfi-39, srfi-55, srfi-61, srfi-62. library is implicit.
    eval
    csi, chicken, extras, srfi-0, srfi-2, srfi-6, srfi-8, srfi-9, srfi-10, srfi-11, srfi-12, srfi-15, srfi-16, srfi-17, srfi-23, srfi-26, srfi-28, srfi-30, srfi-31, srfi-39, srfi-55, srfi-61, srfi-62. library is implicit.

Well great. After that standard dead-end, I've probably run into SRFI somewhere down the line (if not, I'm probably about to google one of these things). Either way, I wind up on the SRFI page.

https://srfi.schemers.org/

OK, there are FOUR hash table SRFIs. I'll go with SRFI-69 Basic Hash Tables. Looking back at those lists, srfi-69 is nowhere to be seen. More searching will sooner or later take me to the official Chicken Scheme SRFI-69 egg which thankfully is documented.

Quite an ordeal. Now, if I want records, I'll know to compare that list of SRFI numbers from the extension page with the SRFI list in the SRFI website. That'll show me that I want SRFI-9. One of two things is going to happen at this point. I might find out that the Chicken wiki has an entry for records. If I miss that somehow (why isn't it in the manual?), then I'll have no choice but to read the entire specification document and be either thankful that it's short, and/or upset that I'm stuck with zero examples (unless I find the wiki along the way).

http://wiki.call-cc.org/man/5/Module%20%28chicken%20base%29#...

https://srfi.schemers.org/srfi-9/srfi-9.html

As you can see, that's not a good dev experience.

Moving away from that, what about compatibility? It's basically not possible to polyfill C FFI, underscores in numbers, primitive IO, exception handling, optional args, and similar. I don't want to play the "does X library work" game (sometimes switching implementations is unavoidable). These things either need to be required or need to be removed from the SRFI list.

Along those same lines, things like records or arrays also need to be required. Sure, they can technically be polyfilled using lists, but the performance of that will make them basically useless.

I understand the "teaching language" bit, but r7rs is already too complicated for an average student to implement. Likewise, "embedded must be small" doesn't hold weight either. Embedded devs expect to have features stripped out. Saying "generators aren't available on tiny platform X" is much easier than saying that "some desktop variants include generator support; good luck".

This is the primary reason why Common Lisp is seen as "business ready" while Scheme is not. Feature Stability, predictability, and documentation matter.