I have also been wondering about this lack. For one thing now that trait functions can be async, by symmetry and language consistency const should likewise be possible. This would give many new possibilities for creating statics. Though if static mut gets banned, only inner mutable ones would be useful.
One candidate I specially think about is Default::default(). I haven't checked, but I doubt this should ever do anything dynamic. If there is code that has it dynamic, then this function is screwed for const. Otherwise it could switch in edition 2024 (probably too late to initiate this change?)
Of course there is, e.g. in std you have Box, Rc, Arc. Even many std collections didn't have const constructors until recently; technically some still don't due to some allocator API hangup I didn't look into. And it's surely prolific in the wild, too.
More generally, it's a breaking change for any public trait to start requiringconst. You need ~const or refinement or a subtrait or such.
As far as I know, everything related to const in traits became part of the more general "effects" initiative. I do not know the status of that.
I agree that "always const" functions in traits are the most obvious kind of const-fn-in-trait. I am not sure if there are any plans to implement that independent of the rest of the effect system (which should allow things like "an impl of Eq where all fn are const").