Remembered this due to @bernsteinbear.com's post (bernsteinbear.com/blog/compili...) reminding me of "An Incremental Approach to Compiler Construction" (scheme2006.cs.uchicago.edu/11-ghuloum.pdf)
There are a bunch of projects/courses based on it's one feature end to end (starting from ints) style

The "tower of macros" style of building a language seems somewhat similar in style if not in practice, I'm guessing. You could consider each "macro"/feature you add as a small compilation pass. See e.g. github.com/metareflecti... Otherwise also popular in lispy languages - though I'm no expert.

One reason is semantics: you need a way to *bind* a variable in a function to a value. You don't need a binder for the return value.
See jesper.sikanda.be/posts/1001-s... for "nameless" IR.
At surface, names have ergonomic/doc benefits, but the return value is documented by the name of the function.

Ah, sorry about the misuse of "sum type" here - not trying to claim/explain those. I was suggesting that instead of typing with a|Null, a|NotFound would still allow recovery of a found Null and not require the nesting of Either/Option.

In other words: optionality of element presence in a list is different from optionality of a found match. An Either/Option here would represent this difference then through nesting structure which also requires correct handling: which level corresponds to element/match, potentially flatten,..

I think that structural/ad-hoc sum types call for a different typing style where this "local" ad-hoc type also uses a local type marking NotFound (not re-used elsewhere except in maybe other find_*) instead of using some global type for any/all optionality like Null.