Hi - a few comments on SRFI-49 (Indentation-sensitive syntax):
1. I _like_ this idea.  Syntax where indentation is significant is becoming
    quite common, e.g., Python, Haskell.

2. I recommend disallowing tab characters, and accepting ONLY spaces.
     If this turns out to be a problem, you can ADD tab characters later, but they're
     hard to DISALLOW later; allowing tabs creates lots of nasty problems.
     Using only spaces ensures that everything looks the same & avoids problems.
    Yes, in theory, tabs are 8 char positions, but a VAST number of folks set them smaller.
    Most text editors can automatically convert, e.g., "expandtab" in vim.
     Instead, why not accept the SRFI while making tabs illegal for now,
     and if there is a hue and cry, accept them later?  Python's Style Guide
     (http://www.python.org/doc/essays/styleguide.html) says this:
    "Use the default of Emacs Python-mode: 4 spaces for one indentation level
     For really old code that you don't want to mess up, you can continue to use
     8-space tabs. Emacs Python-mode auto-detects the prevailing indentation
    level used in a file and sets its indentation parameters accordingly....
    Never mix tabs and spaces. The most popular way of indenting Python is
    with spaces only. The second-most popular way is with tabs only. Code
    indented with a mixture of tabs and spaces should be converted to using spaces
    exclusively. (In Emacs, select the whole buffer and hit ESC-x untabify.)"

3. I suggest spec'ing a way to enable or disable this mode.  That way,
     we all know how to, portably.  You can even begin files with that, to make
     SURE that the file can be read correctly.  Whether or not it's a default
     I leave to the implementors.

4. The text defining this doesn't seem clear/correct.  Here's what it currently says:

"In the following syntax definition, this initial space, as well as linebreaks, is not included in the rules. Instead, preceding any matching, the leading space of each line is compared to the leading space of the last non-empty line preceeding it, and then removed. If the line is preceeded by more space than the last one was, the special symbol INDENT is added to the beginning of the line, and if it is preceeded by less space than the lastt one was, the special symbol DEDENT is added to the beginning of the line. It is an error if neither one of the leading space/tab seqquences are a prefix of the other, nor are they equal."

There's a typo in the above with "lastt".  But more importantly, this text seems to imply
that only one de-indent can occur on a line.  But that clearly is NOT true, e.g.,
the "define" example clearly ends all the s-expressions at once.

The text should give the "simple meaning" that I think was intended here. Something
like: "every indent starts a new s-expression (with rest of the line
giving the beginning of the s-expression), every line at the same indent level
as a previous line simply adds new components to the s-expression of the same
level, every de-indent closes the previous interior s-expressions, and a
completely blank line closes all active s-expressions."

5. The SFRI text should include at least a "sample" pretty-printer, with the
same MIT-style license.  E.G., this one (or an improved version):
  http://srfi.schemers.org/srfi-49/mail-archive/msg00008.html

6. If there was a standard way to invoke a pretty-printer that displays
in I-expression format (not necessarily implemented using the
sample code), that'd be great too.  Just define how to invoke it
(just like my previous request on how to enable/disable the mode).

Hope that helps.

--- David A. Wheeler