The Hashtable Problem: A Litmus Test for External Impl Proposals

There's another wrinkle to this which is type-erasing/type-keyed hashtables, which a "plain" solution over static typing may not catch. You can best read my attempt (not independently reviewed) at solving both here: rust-rfcs/text/3634-scoped-impl-trait-for-type.md at 251e4c443757ebe7c079a8a3627e32f9b79d4d0e · Tamschi/rust-rfcs · GitHub (version-agnostic link, in case I update it, in case I update it).

There's another common problem with orphan-rule relaxations, which is external-global implementation mixing in multi-trait bounds breaking cross-impl proofs valid for existing code: https://github.com/rust-lang/rfcs/pull/3634#issuecomment-2153325753 This can be worked around without changes, but in my opinion that would break ergonomics badly for what in practice is a very rare problem. I think it's feasible to change what impl blocks can assume across an edition boundary though, along with an attribute to apply the previous mixing constraint explicitly. I haven't (yet , hopefully) found the time to revise for that, though, so my RFC is unsound in that regard. You can find a sketch of a possible solution in the GitHub comments, starting here: Scoped impl Trait for Type by Tamschi · Pull Request #3634 · rust-lang/rfcs · GitHub