This is a nice example. I agree they are different in the natural reading of each.

Specifically, suppose both features had been added to the language. I would expect foo1() to print "3" and foo2() to print "4".

This is also a good example of why the more general feature is BETTER. It is easy to emulate the foo1() behavior with 'defer', but impossible to emulate foo2() using '=>'.

E.g.

def foo3(a=defer [1,2,3], b=defer len(a)):

    # behaves like foo1()

    b = b  # or eval_b = b and use new name in body
    a.append(4)
    print(b)

Note this:

def foo4(a=defer [1,2,3], b=defer len(a))

    print(b)  # prints 3

In order to print we actually need to walk a DAG. 'b' is an "unevaluated" object, but the interpreter would need to recognize that it depends on unevaluated 'a' ... and so on, however far up the tree it needed to walk to have only regular values (or raise a NameError maybe).

This is all precisely prior art, and is what is done by Dask Delayed: https://docs.dask.org/en/stable/delayed.html

I think it would be better as actual syntax, but generally Dask already does what I want.

The amazingly powerful thing about constructing a DAG of deferred computation is that you can find only intermediate results in a complex tree if that is all you concretely need.

I recognize that this is more complex than the niche case of late evaluation of formal parameters. But I consider that niche case trivial, and certainly not worth special syntax.

In contrast, the niche case falls out seamlessly from the more general idea.

In terms of other prior art, deferred evaluation is the default behavior in Haskell. I admit that I find strictly functional language with no mutability a PITA. But inasmuch as Haskell has some elegance, and sometimes reasonably fast performance, it is largely because delayed evaluation is baked in.