This maybe?: [Pre-RFC] Scoped `impl Trait for Type` - #20 by Tamschi
Probably not exactly what you were referring to since that specifies anonymous module-addressed implementations (which is helpful for subsetting generic implementations in that RFC). It's in principle very similar to what was proposed here, though, at least in terms of type system interactions, and discusses afaik all the edge cases that have come up over time.
The main formal issue that proposals like this run into is that currently you can make unsafe assumptions about bounds-linked implementations, which makes solutions like this either:
a) unsound,
b) make implementation of traits a SemVer hazard in general or
c) introduce more friction (require unsafe) to reuse of global implementations in those combinations.
I went with[1] c) in my RFC (unsafe use ::{impl Trait for Type}; to allow it consumer-side, and/or a boolean attribute impl-side), but considering how much of a niche case that likely is in practice, I still think it would be sensible to flip the default for whether a global impl Trait for Type can safely be combined with non-global impls elsewhere as part of an edition.
(There are also "soft" issues related to friction at crate APIs, though I think a proposal that distinguishes types and is always explicit, like this one here, should have fewer of those.)
I still haven't gotten around to actually revising the RFC with this fix properly, but it's outlines fairly unambiguously in the GitHub comments at least
↩︎