> It also avoids splitting predefined operators
in many sub-libraries (ex: (srfi 266 flonum)) that I failed to imagine
how it can be composed (ex: (import (srfi 266 flonum) (srfi 266
fixnum)).

You don't have to do this with hygienic matching: (srfi 266) could just
export all identifiers, and then raise an error if operation fl+ or
whatever is used but not supported.

 > I checked identifier-property and it looked promising on the paper but
I noticed that there is very few implementations. Peter points
Capy scheme and srfi 262. I have to check. It will take time...

This is relevant for hygienic-matching+extensibility. If you go for
hygienic matching, I would just cut out the extensibility section in
this SRFI. Then the whole thing could be implement in syntax-rules. (I'm
not telling you to rewrite the whole implementation to do that!) Then
later on, if identifier properties are more widely implemented, then you
(or someone else) can backwards-compatibly extend the syntax with
extensibility.

________________________________________________

 > It implies that part of the specification is to be rewritten. I have
to check. It will take time...

I think addressing Marc's point is simple.

The spec uses "parentheses" and "spaces" to mean "lists" and "separate
elements of a list." These are pretty commonly interchanged when talking
  informally, but are confusing when we talk about parsing. By replacing
these you should be able to fix the problem.

My suggestions:

Your text:

 > The arguments are either a single expression or a subexpression in
parentheses. When it is a subexpression in parentheses, the arguments of
the call are separated by spaces.

This should read

 > The arguments are either a single expression or a list subexpression.
When it is a list subexpression, the arguments of the call are the
elements of the list.

Your text:

 > Subexpressions are expressions enclosed in parentheses.

Should be:

 > Subexpressions are list data (i.e. lexically, they are enclosed in
parentheses).

Your text in the description of "call":

 > Space separated arguments.

Should be removed.

Your text:

 > Expressions can have subexpressions in parentheses.

Should be:

 > Expressions can have subexpressions, which are list data (i.e.
lexically, they are enclosed in parentheses).

Your text:

 > When argument of a call, spaces are interpreted as separating arguments.

Should be:

 > Each element of the list is interpreted as an argument to the call.

_______________________________

 > I was thinking I used R6RS macro facilities, but Marc tells I don't,
so I have to check. It will take time...

If the above changes are made, I think this point is addressed too.

_________________________________

I really like this proposal and I hope it is finalized.

-- Peter McGoron