@JaneOri Purely as an author-expectation language design issue, I think there's reasonable arguments both ways.

I came down in favor of the behavior split so we *could* do short-circuiting. There's a more ideal CSS where this is more consistent across the board, but we work with what we've got.

@JaneOri The *secondary* benefit of it is predictability. When you write `--my-func(1, var(--arg), 3)`, you very likely expect the arg to set the second argument. But in the earlier pre-spread version, it `--arg` contains commas, it would set *multiple* arguments. You could defensively wrap it like `--my-func(1, {var(--arg)}, 3)`, but we don't expect people to remember to do that.

The new spread behavior makes it work as we think people will expect, by default.

@JaneOri The short-circuiting isn't really a speed benefit (tho it does accomplish that a little); instead, it prevents later *unused* variables from creating reference cycles that'll affect earlier variables.

Note as well that this isn't just custom functions, it's *all* "arbitrary substitution functions" - var(), if(), attr(), etc. Anything that can emit an *arbitrary* token sequence in any location has this spread behavior, now.