Consider presenting this information more like this, instead:

Function definitions have one of the following syntactic forms (where items in square brackets are optional and independent):

fn [name] [ implicit-params ] [tuple-pattern] => expression ;
fn [name] [ implicit-params ] [tuple-pattern] [-> return-type] { statements }

The first form is a shorthand for the second: "=> expression ;" is equivalent to "-> auto { return expression ; }".

implicit-params consists of square brackets enclosing an optional default capture mode and any number of explicit captures, function fields, and deduced parameters, all separated by commas. The default capture mode (if any) must come first; the other items can appear in any order. If implicit-params is omitted, it is equivalent to [].

The presence of name determines whether this is a function declaration or a lambda expression.

The presence of tuple-pattern determines whether the function body uses named or positional parameters.

The presence of "-> return-type" determines whether the function body can (and must) return a value.

That's more abstract, but at least for me, it would make it much easier to see how this design is (and isn't) continuous.

Awesome! I added this content right above the part that you highlighted. My reading of it is that these two blocks of text are not mutually exclusive. Do you disagree?

I agree they're not mutually exclusive. Personally I don't find the table and examples helpful, but they may work better for other people.

I agree they're not mutually exclusive. Personally I don't find the table and examples helpful, but they may work better for other people.

I think we should specify this slightly differently:

This is more general than what we've discussed so far, because it allows things like fn [(a: auto, b: auto) = Foo()] {...}, but that generalization seems desirable.

Suppose I want to write this:

let a: String = "long string I'd rather not make a copy of";
DoThingWithLazyGetter(fn [???] => a);

Can a ref capture be used to capture a let binding? If so, what happens -- does that create a temporary and capture a reference to it, or does that capture a value as if by [a: auto = a]?

If not, I think the outcome is that there isn't a way to capture a let binding without renaming it. You can use a function field, but our name shadowing rules would suggest that you must use a new name for the function field. I wonder if it'd be worth adding syntax for capturing a value as a value, rather than as an object.

I think we still need an answer here -- I think wanting to capture a local let binding will be a common case, and requiring it to be renamed seems unsatisfying from an ergonomic perspective.

This leads question has now been answered: #3860