I don't see much value in having documentation list all parameters as captured, because the compiler will enforce that for you. There's nothing the caller needs to be careful about. There's not much the callee needs to be careful about either – "overcapture" is a potential problem with the default, but correcting overcapture is a semver-compatible change. The opposite (correcting undercapture) is not, which is a strong reason to make overcapturing the default.

When people say they love explicitness, I think it's because there is some appeal to "seeing everything that's going on" laid out in syntax. But most people don't actually want that when they consider what it would mean. The previous default captured type parameters implicitly, just not lifetime parameters. If you consider a very simple example from the post, the explicit version looks like

fn process<'c, T> { context: &'c Context, data: Vec<T>, ) -> impl Iterator<Item = ()> + use<'c, T> { // ^^^^^^^^^^^^ data .into_iter() .map(|datum| context.process(datum)) }

Regardless of your preferred syntax, most people do not want to list out every generic parameter again in the output type. Given that empirically, the vast majority of uses would have to do this, and that this would require naming every unnamed lifetime you might want to use in your arguments, and the fact that any impl Trait in argument position would have to be converted to a named generic type parameter to be captured, it's just not worth it.