The main problem with ?Trait bounds is that they are very unpleasant to work with, especially in a backwards compatible way. If you want to add a new one and use, then all new generic code should be polluted with endless bounds like T: ?Trait. Why? Because there are a lot of other crates that depend on Trait be implemented.
What if we allow crates to set which bounds are assumed by default and which not? That way crate foo might remove Sized from defaults, and manually write Sized where needed and never write ?Sized, while any dependencies/users of that crate would not feel any change.
I think the current trend of this thinking will at least incorporate negative impls. I can't comment on the ultimate ergonomics there, but I doubt that I would ever want to set assumed traits crate-wide. Perhaps smaller scopes would make sense, if you want to try some examples.
I am not sure how negative impls are related. Per crate trait defaults articulated here are more like syntactical helper, not something actually changing trait solving, as negative impls are.
About the scope, I don't think this is really important at this point, it might a module as well.
What I am concerned about is hesitance to ?Trait bounds, kind of backwards compatibility trap. That idea, as I see it, can remove that particular problem, with old crates having old assumptions while new crates not having to drawn in boilerplate related to new ?Trait bounds.