However, i think a good case was made that with some combination of
tools and debugging modes, the problem can be solved with a quite
reasonable amount of effort. Furthermore, it's extrememly easy, and
arguably good style, to write Scheme and Emacs Lisp code that doesn't
depend on the result either way, and this seems to have no down-side.
For the most part, this style consists of writing "(not (null ...))"
when using a list in a boolean context, which many people already do.
Of course Lisp doesn't have type declarations, but i argue that these
types are fairly clear conceptually. It's really no different from C:
there's no boolean type, but programmers typically write "if (x != 0)"
or "if (p != NULL)" even though these tests aren't `necessary'.
I think that it's unfortunate if absolute compatibility with Emacs Lisp
becomes the ultimate dictating factor for all Guile decisions. If an
Emacs Lisp system is built on top of Guile, most likely it will have
some minor inconsistency anyway, presumably for various good reasons.
Indeed the criterion seems somewhat unreasonable; for example, following
this rule, Emacs 19 must be rejected out of hand. I ran into some
compatibility problems in my code, but it wasn't a major deal.
There's some problem either way, but it can be handled and it shouldn't
be considered a major stumbling block. Given this, i prefer the Scheme
convention and i think that it should be the native mode for Guile.