Lojbanの文法用語はLojbanで説明するのが正確で、英語の文法用語に訳すこともできるけれど完全には対応しないので確かに理にかなっていた。そのライブラリを使うのは大体Lojban話者だし

John Cowanは “The Complete Lojban Language”（通称CLL）の著者で、Lojbanの合成語を語根に分解するライブラリ（だったと思う）をChicken Schemeで書いていたのですが、このライブラリのコメントも手続き名もライブラリ名自体もLojbanなのがかなり力強かった

R7RSのeditorであるJohn Cowanは処理系作者ではない（Schemerなのは以前から知られていた）のが異色だったりする

R7RS largeに入るにはSRFIが必須とされているので、SRFIの策定プロセスで議論が進められ、R6RSのような分裂を避けていこうという方針（だけどまだfinalになっていないSRFIが内定したりして若干不穏がないでもない）

低レベルマクロ、explicit renamingがR7RS largeに入るといわれているものの、現時点ではまだそのためのSRFIが書かれていないはず

Implementing R7RS on R6RS Scheme https://www.slideshare.net/katotakashi16/implementing-r7rs-onr6rsscheme

Scheme '14 http://www.schemeworkshop.org/2014/

Sagittariusの作者はR6RS処理系上でR7RSを実装して発表したので徐々にR7RSに集いつつある現状に大きく貢献しているという認識

PythonはCPythonが圧倒的な支配力を持っているけれど、Schemeは得意分野の違う様々な処理系が共存しているので割と違う

私の主観ではPythonより荒れてた（R6RSのドラフトに対する投票で処理系実装者も賛成派と反対派に割れて、一応必要な賛成票は集まったけれど反対派のグループがERR5RSを提唱したりしてなんだかんだあってR5RSとの互換性を重視したR7RSができた）

R5RS：現代的なライブラリシステム（モジュールシステム）がない、シェルスクリプトのsourceレベルの機能ならある
R6RS：ライブラリシステムを追加した
R7RS ：ライブラリシステムの設計をやり直した

SRFI込みなら機能面でどちらがどうということはないんですが、ライブラリシステムに互換性がないので両対応にするにはコツがいる