This is an extremely well-written and readable post. Nice and to the point. The use<T>, use<>, 'static trick is really fascinating and made me understand the issue at hand better. E.g. in the last example since the type of "the length of the slice" is irrelevant to "the type of slice" we ideally want to be able to express that in the type system. As an Agda developer, and a proponent of formal methods, it's very pleasurable to see these kind of novel PLT ideas being used in a mainstream language.

The implications of this on async seem tremendous. I'm a believer of async, even though it did do quite a bit of damage to the ecosystem, in the long term I bet on it being the correct abstraction (and Rust's implementation being close to the correct implementation). I think this change will make async more convenient and less restrictive to use.

Big kudos to Rust compiler devs about their sophisticated type system and its kind (and highly intelligent) help messages. A little concern is that AFAIK its complexity in type systems and other static analysis things require deep domain knowledge, so in a far, far future there may be a lack of "core" engineers comparing to a demand much increased at that point. This kind of change looks like already requiring deep understanding of both Rust's type system and internal compiler structure to implement.

Rust as a language has a complexity threshold already exceeding C++ in readability within a decade of existence. Adding things like + `use<T>` at the end of an already complex return type doesn't really help matters.

    fn indices<T>(
      slice: &[T],
    ) -> impl Iterator<Item = usize> + use<T> {
        0 .. slice.len()
    }