@JaneOri [...] which is that a `var(--foo)` call, particularly when nested into a function call like `--bar(1, var(--foo), 3)`, *looks* identical to `bar(1, foo, 3)` in JS or similar languages. There, you know for a fact that the foo variable, whatever its value is, fills exactly the second argument and no more.

If you want more, you write `bar(1, ...foo, 3)`, making it explicit. That's exactly what the CSS functions are doing; direct knowledge transfer across web languages.

@JaneOri There have been counter-arguments; you just disagree with them.

The issue is arbitrary-substitution functions in general. We need to be able to tell where the argument boundaries are, so we can do things like not evaluating `var()` fallback unless needed, or short-circuiting in `if()`, etc. Spreading is a special case there.

There's also a more direct DX argument for it [...]

@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.