> they could have something like this:

Could in some purely theoretical way, but this is pretty much exactly the same, minor syntax differences aside, as virtually every other failed proposal that has been made around this. It would be useless in practice.

In the real world it would have to look more like this...

    func printSum(a, b string) result[error, unit] {
        return for {
            x <- strconv.Atoi(a) else (err error) {
                details := collectDetails(a, b)
                stop firstConvError{err, details}
            }
            y <- strconv.Atoi(b) else (err error) {
                stop secondConvError{err}
            }
        } yield fmt.Println("result:", x + y)
    }

or maybe something like this

   func printSum(a, b string) result[error, unit] {
        return for {
            x <- strconv.Atoi(a)
            y <- strconv.Atoi(b)
        } yield fmt.Println("result:", x + y)
    }

    handle(printSum, "x", func(vars map[string]any, err error) {
        details := collectDetails(vars["a"].(string), vars["b"].(string))
        return firstConvError{err, details}
    }

    handle(printSum, "y", func(vars map[string]any, err error) {
        return secondConvError{err}
    }

...because in that real world nobody just blindly returns errors like your contrived example shows[1]. There are a myriad of obvious (and many not so obvious) problems with that.

Once you start dealing with the realities of the real world, it is not clear how your approach is any better. It is pretty much exactly the same as what we have now. In fact, it is arguably worse as the different syntax doesn't add anything except unnecessary complexity and confusion. Which is largely the same reason why all those aforementioned proposals failed. Like the linked article states, syntax is not the problem. The problem is that nobody to date knows how to solve it conceptually without completely changing the fundamentals of the language or just doing what you did, which is pointless.

And there is another obvious problem with your code: result[error, unit], while perfectly fitting in other languages designed with that idea in mind, is logically incorrect in the context of Go. They are not dependent variables. It doesn't make sense to make them dependent. For it to make sense, you would, as before, have to completely change the fundamentals of the language. And at that point you have a band new language, making any discussion about Go moot. That said, I think the rest of your idea could be reasonably grafted onto the (T, error) idiom just as easily. However, it still fails on other problems, so...

[1] Which, I will add, is not just speculation. The Go team actually collected data about this as part of their due diligence. One of the earlier proposals was on the cusp of acceptance, but in the end it wasn't clear who – outside of contrived HN comments – would ever use it due to the limitations spoken of above, thus it ultimately was rejected on that basis.