The concept of editions is that they allow change without breaking backwards compatibility by always being supported. So that would be Rust 2.0.
No, the exact same examples apply when a non-'static lifetime is in play.
You mean, by making use<'a> act like a bound? That would have the same downsides that let to lifetimes being captured by default (applying a bound to other generics unnecessarily).
No, it should be deliberate, and in my case it is. I'm making a promise that the return type meets the stated lifetime bound -- just like I'm making a promise that it meats the stated trait bounds. By making that promise, it's a breaking change to start materially containing the other captured generics. And the type system exploits this, as demonstrated.
If I don't make that promise, it is a non-breaking change to start materially using the other captured generics. So it is not the case that the promise I'm making by including the bound must (or should) always be true.
I do agree that there could be other ways to solve the examples I illustrated in the future, such as TAIT (albeit less ergonomically), being able to omit type generics with use<..>, and perhaps existential lifetimes.
Until we have them, discouraging + 'a is premature. And even if we get them, I still wouldn't agree that deprecation is warranted.
(I also suspect we'll never be able to not capture Self with opaques in traits and thus + 'a will retain some unique capabilities, but it's all hypothesizing about the future at that point.)
On this I don't agree. The examples show how they enable type-erasing coercion to dyn Trait + 'static (and thus to Any and a usable TypeId), and how they enable more lenient borrow checking.
If your argument is that these capabilities are nonsense, please show how to remove the bounds from the playground above in a non-breaking manner.