I definitely agree that the current SRFI-28 is much too minimalistic and
that we need an intermediate format (and possibly later an advanced
format).  But I think that an intermediate format should at least be a
superset of C's printf functionality; specifically it should include
support for floating point formatting with ~F (I think ~E and ~G would
be advanced).

I don't think ~P belongs in the intermediate version, but would
recommend reserving that character for the advanced version for
backwards compatibility.  With one-letter names, some of them are going
to be poor mnemonics no matter what so you might as well be consistent
with CL.

Shouldn't we have a pretty-printing SRFI before using it in our format?

I agree with the arguments for a more functional style, but think this
should be implemented by breaking the format specs into separate public
procedures and having the format procedure dispatch to them.
Customizing a format string in one place is too useful to ignore.  As a
possible extension, format could be re-factored in terms of a
lower-level make-formatter procedure such as:

  (define format
    (make-formatter
     #\a format-display
     #\w format-write
     #\x (cut format-radix <...> 16)
     ...))

thus allowing people to customize their own format strings for
domain-specific use (e.g. SRFI-19 date->string could be defined in terms
of this).  You could modify this to take a first argument as an
inherited formatter:

  (define format
    (make-formatter
     SRFI-28-format
     #\x (cut format-radix 16 <...>)
     ...))

which would use the local definition for #\x but fall back on the parent
for #\a and #\w, allowing us to build up hierarchies of formatting.

Random thought, to address the "value is distant from format spec"
argument by Marc Feeley we could define a format macro which reserved
format-looking symbols:

  (macro-format "name: " ~A name ", cost: $" ~F 2 cost)
  => "name: apple, cost: $1.50"

This would also allow longer, more descriptive names, without being as
long as the general procedures names are likely to be.

--
Alex

Note, I've got an implementation of format which is somewhere between
the current SRFI-48 and full CL format at:
  http://synthcode.com/scheme/cl-format.scm