Hi Yuval, hi Tomas,

I empathize with all your pains (skipping arguments, reordering them,
nested calls.) However, I have several arguments in favor of not
extending cut/cute:

• It is not intended to replace lambda, there are ^ (Gauche, IIRC) and λ
  (Guile) for that. It is intended for mainly one-argument throwaway
  procedures.

• Nested expressions can be expressed with compose + swap? + cut +
  lambda?. This is sufficient for many cases. Not all, but many. Tomas’
  case cannot be expressed with compose et al., for example. But it’s
  already (barely) complex enough that writing a lambda with explicit
  readable names is better than exploiting cut.

Yuval, the worst thing if that can happen if you submit an SRFI is that
no one will adopt it. If you’re fine with that and with spending some
time on writing up the document and implementation (which I assume you
partly did already,) then you’ve nothing to lose.

In case the SRFI will not be adopted, you can:

• Contribute it yourself (that’s what I did with SRFI 253 in most
  implementations, because I’m motivated to write strictly-checked
  Scheme code and because I’m unemployed haha.)

• Use it as a library or copy-paste macros in your projects.

So yeah, SRFI away!

Best of luck,
--
Artyom Bologov
https://aartaka.me