Hi, I would like to make a couple of remarks that came to my mind when I first read your proposal. In no particular order: 1) The SRFI says that "(is x < y <= z)" is syntactic sugar for "(and (< x y) (<= y z)". However, it should be syntactic sugar for "(let ((%y y)) (and (< x %y) (<= %y z)))" because evaluating "y" may have side effects (or just be costly). In case of the former expansion, "(is x < y < z)" would be something different than "(< x y z)".
2) As for the "pronounciation" of "(< x y)" and so on: It is in the report in 6.2. The report talks about (a list of) "monotonically increasing" numbers. This makes very much sense because "<" is not a binary predicate but an n-ary predicate for any n greater or equal 2.
On the other hand, I agree that it is less obvious for a predicate like "divides?" (although it makes as much sense as for "<" to make "divides?" an n-ary predicate because, mathematically, "divides?" defines just another (non-total) order). However, "(is x divides? y)" doesn't follow the English grammar rules. One would first have to redefine "divides?" to, say, "divisor-of".
3) For consistency, it would be nice if SRFI 26 and this SRFI use the same placeholder, so either "<>" or "_". If people agreed on "_", we would need another SRFI amending SRFI 26 (and SRFI 148, which reuses SRFI 26's identifiers for consistency). In the latter case, one would have to cope with the identifier "<...>" of SRFI 26 as well. One possibility would be to use ". _" (because "<...>" only appears as the last element in a list in SRFI 26).
4) Being a mathematician, I don't understand why "(is _ < x < y)" is allowed, while "(is x < y < _)" is not allowed It seems like an artificial restriction complicating the spec (while the implementation would still be straight-forward).
5) From a user's point of view, "(is _ + 1)" looks like a valid use case. I understand why you discourage its use, namely because the word "is" simply does not make sense with respect to addition. Why don't you use an otherwise unused symbol? E.g. "$"? Then writing "($ x < y)", "($ x taller-than? y)", "($ x divides? y)", "($ _ + y)" each makes a lot of sense. (I don't want to say that "$" is a particularly good choice; consider it as a meta-identifier for the moment.)
So what I want to say is that one of Scheme's selling points is that its primitives are very orthogonal and the few concepts it provides are not unnecessarily restricted. Now, SRFI 156 seems to restrict its own applicability for natural language reasons. There should be a solution to this problem.
6) Does this SRFI provide enough reasons for people to switch from "(< 1 2)" to "(is 1 < 2)"? If not, Scheme code would possibly become harder to read because one will have to know both conventions when studying other people's source codes.
Let me give two examples to demonstrate my point: Scheme has the named-let and the do-construct as the primary means to write loops. Do-loops are easily rewritten into named-let-loops. However, they add a bit of meaning. A do-loop (with a non-trivial body) is an imperative construct, which I can so mark in my Scheme code. At the moment, I don't see any meaning that is added when using the "is" form proposed in this SRFI (as much I don't see any meaning added when using the square brackets of the R6RS as opposed to the round brackets).
The syntactic sugar "(define (f x) ...)" for "(define f (lambda (x) ...))" does not add any meaning, but it shortens the code, so people use it (somewhat) consistently.
P.S.: I am willing to help you with the sample implementation if you want to incorporate some of my suggestions (e.g. "_" is position 3 or later, or to code the "let"-wrappers) and if you don't like macro programming too much (or take a look at SRFI 148, which makes programming or powerful macros very easy).