It's more about ...

OK, I get your points - it's more about working on that vision, and not exactly starting with the low-hanging fruits, which was were my corporate-tainted mind did lead me to ;) There is this one bit that nags me:

I'm surely the least-Scheme-educated person in that whole business, so this is an outsiders position, but still: for me the charming thing with Scheme is that it's a very well thought out nucleus that has been honed over decades to something very useful (and just so elegant), and still simple enough that it can be applied in different environments (executable, byte-code, small R5RS to Racket size, JVM, .Net, JS, soon probably WASM) and with different foci. Sure, there is overlap between implementations, still every implementation has its unique selling points. And they all exist, because the ratio between functionality and barrier to entry for a new Scheme is higher than elsewhere (denominator is smaller for FORTH, but numerator for a general purpose language even more so).

So once I understand Scheme, I can apply its basic ideas in vastly different environments. And even if I cannot also expect all libraries being transferable, that's still wort a lot; otherwise I might still use SBCL (and miss the elegance). So I personally would be careful with putting so much of a "compatibility-tax" on any Scheme implementation, that the creativity in Scheme, which is still strong after so many decades, starts getting hampered. In my impression R7RS and the SRFIs are this side of becoming such a risk - now putting in more "organization" might not only bring the benefit of simplified reuse, but it might also become a burden for creativity.

There is already Python for the pragmatic crowd, there is Racket for pragmatic Schemers, so there is value in keeping some free headspace.

I'll try to see if we can extract something useful from theschemer.

Not required; it's not that I want to cherry-pick were I work on ;) I'll take a closer look and see whether I find a way to approach this.