I was writing a reply explaining what points I felt terrible
about c-exprs, but you summarized them well in your new message,
so I can just rephrase them:

- Mentally parsing mixture of c-exprs and s-exprs are hard, especially
  when they appear alternatingly.
- S-exprs works better in multi-line expressions.
  (C-exprs is more verbose (in n-ary cases) and that makes it worse.)

N-exprs address these issues, as you said.   I think T-exprs also
helps a lot to alleviate the first problem, since it tends to strip
the "outer" s-expressions and reduces the need of flipping switch of
the mental parser.

Without the support of n-exprs, probably c-exprs would be used
only for small, leaf expressions.   Whether it is still worth a
troulbe or not is debatable; I wouldn't support c-exprs alone.

C-exprs and n-exprs are technically orthogonal, and you split
them partly because for the ease of adoption.  But I feel that
combining them increases their appeal a lot for wider adoption,
while supporting only one doesn't seem likely.

Supporting n-exprs only in c-exprs may seem technically inelegant,
but how about seeing it as a starting point?  To me it seems easier
to flip switch once I enter '{}' world, so I don't mind if the
syntax is different in '{}' from outside '()' world.
Plus, the full n-expr is upper compatible to "n-expr inside {}",
and it may be easier to discuss after people get experience
using n-exprs in {}.

Or, supporting full "readable" project once is also easier than
supporting individual elements.  I read the full sweet expressions
as a totally different syntax; again, no need to flip the switch often.