> I think this interpretation is right: there is a clear "easy answer" here. But it is unsatisfying.

It seems like that actually mostly solves the problem though? Syntactically, there are four relationships a type parameter can have to a trait:

  <T>         // dunno
  <T: Leak>   // needs leak
  <T: !Leak>  // needs not leak
  <T: ?Leak>  // don't care about leak

But `<T>` isn't actually a semantic possibility; it effectively gets desugared to `<T: ?Leak>` ("don't care") unless Leak is a ?Trait.

> The problem is that as a consequence, any 2024-edition trait that doesn't have Leak bounds on the generics in its functions cannot be implemented in 2021-edition code

In "edition 2021" `<T>` desugars to `<T: Leak>`, which is not "don't care about leak". But 2021 code can still use `<T: ?Leak>` to explicitly not care about leak, just like it can use `<T: ?Sized>` to explicitly not care about size. (So 2021-edition code can implement 2024-edition traits that don't have Leak bounds, it just has to write the lack-of-Leak-bound explicitly.)

In "edition 2024" `<T>` desugars to `<T: ?Leak>`, (and `<T: ?Send>`, and `<T: ?RandomOtherTrait>`, etc, but that's not a change). (2024 code can still explicitly declare `<T: Leak>` if it wants, as noted.)

So in the desugaring interpretation, the only thing you've changed is the default trait bound; all the semantics are still there. 2021 keeps the conservative, backward-compatible convention, which can't actually use !Leak types very much due to running into traits like Iterator or Deref, but can (explicitly) support !Leak types in most generic interfaces. Meanwhile, 2024 uses the actually-useful convention, and can opt-in to `<T: ?Leak>` versions of Iterator et al piecemeal, with the `<T: Leak>` versions being automatically derivable.