The problem with the name match-> is that all the other -> forms imply splicing, which is not present in this macro.

Yes, that is definitely confusing. Another thing to keep in mind is that currently all similar short-circuiting forms tend to have a ? in their name, which is a good convention in my opinion. Would it be a bad idea to simply call this form e.g. match-?? (match? looks too much like a predicate function.) On the other hand, try pairs nicely with catch. These names, however, are a bit more obscure in that they do not imply sequencing.

I think catch is much better as it implies it catches mismatches that happen in any step.

Exactly.

Something like this would indeed be a great addition, but the diagonal pairing without nesting makes the suggested form a bit surprising, and harder to understand intuitively than the usual when-let* macro from Lisp/Clojure folklore. There's nothing inherently wrong with it I guess, except for going against convention, but any such maybe monad equivalents that come to mind - a Haskell do block, or even the cited with form of Elixir - are usually arranged as pairs of bindings stacked on top of each other:

(when-let [filename (get-file-name-for user)
           file (io.open filename :w)
           file (file:write data)]
  (notify user))

Makes perfect sense to me too (after all, this was my initial intuition).

I'm not so sure about that... &as preceding & rest would be very confusing and counter-intuitive IMO. (One might think that &as refers to the preceding arguments only.) At the very first position - [&as all x y z & rest] - it might make a bit more sense, but still hard to read. (Definitely better than in the middle though.)

Sure, here's a real-life example from a Neovim plugin - a rare, but valid use case, when the head (first), the tail (rest), and the whole table (positions) are all referenced later. (This occurs at maybe one or two other places in that script.)

> (local [a b & rest &as t] [1 2 3 4 5])

Compile error in unknown:12
  expected rest argument before last parameter

* Try moving & to right before the final identifier when destructuring.

It would be great if this case could be handled somehow, as it would allow for eliminating a let-block and a nesting level in many places.