Reunificando Scheme

Menos de dos años han pasado desde la polémica 6ta revisión del lenguaje Scheme (R6RS), que causó una ruptura de la comunidad. El lenguaje siempre se caracterizó por ser puro y minimalista hasta que este nuevo estándar duplicó el tamaño de la especificación.
En el proceso de ruptura apareció un movimiento para mejorar R5RS, pero manteniendo el lenguaje fiel a sus principios, así nació ERR5RS.
Scheme nunca se convirtió en un lenguaje práctico para el despliegue de aplicaciones, debido a que muchos aspectos de la implementación no eran parte del estándar, dificultando la interoperación del código entre las diversas implementaciones del lenguaje, así que la comunidad de scheme siempre ha estado de una u otra forma dividida, sin embargo R6RS causó una gran fractura, con la mayoría de los fabricantes quedándose en R5RS o migrando a ERR5RS, mientras las implementaciones grandes se fueron por la vía de R6RS.
Esto es una lástima porque los fundamentos matemáticos sobre los que se basa Scheme son muy formales, de hecho toda la semántica del lenguaje está definida matemáticamente a usando semántica denotacional.
Hace unos días para mi sorpresa se activó nuevamente la lista de discusión de R6RS, y la discusiones que vi fueron sobre la división del lenguaje en dos versiones y los posibles nombres que se le darían cada versión!
En un esfuerzo por reunificar la comunidad se piensa en que la próxima versión de Scheme (R7RS?), tendrá una versión light que permita implementaciones pequeñas y mantener a los puristas contentos, mientras la versión pro sería más pragmática, con énfasis en la implementación y desarrollo de sistemas y en interoperabilidad entre las versiones de los diversos fabricantes de compiladores, esta versión profesional podría incluir  un sistema de módulos y una librería estándar.
Ojala este nuevo esfuerzo pueda reunificar nuevamente a la comunidad sin convertir Scheme en un nuevo Common Lisp.