It makes me worried, because the implementation now became
very abstract, and it no longer conveys the intent: it doesn't tell
the reader how the "is" macro is meant to be used, which I think
is a big price to pay -- especially given that the behavior that it enables
is questionable and discouraged and unlikely to be used in practice:

As syntax-rules macros usually have to be written in convoluted ways, I don't think one should every take them as a definition of a new concept.

I expect specialization of a single argument of a binary predicate
to be the most common use case, which in my view justifies
the irregular behavior.

(is _ < x < _) looks like a sensible application. It is a procedure of two arguments, say a and b, and returns #t if the interval [a, b] encloses x.

It also prompts to consider another interpretation, where "is" would always
be returning a lambda, and so instead of (is x < y), one would need to
write ((is x < y)). I don't think there's any utility in such consistence,
but I'm mentioning it for consideration.

For consistency, I think it is very imported that the "is" macro does behave regularly. Either it should always return a procedure or never.

If you don't want to write ((is x < y)), I suggest to use two different syntaxes. (E.g., as previously suggested, (cute is ...) for the procedure case.

Marc