At the very least you'd need a different syntax, to disambiguate this for the parser.
That's the biggest issue with this. Since Rust 2021 is proposed, and this playground example works, there's a good chance of this change entering Rust pretty soon if an RFC is composed. (Would it be a good idea to make one myself? I have never contributed to the Rust compiler of the RFCs before, so I don't really know where to start.)
it might not be the highest priority because other workarounds are possible
Passing &self to a method which is meant to be associated, or worse, having a &selfified version of it is horribly, horribly wrong from a semantic standpoint, screaming "I'm a hack to overcome language limitations". Redesigning code to avoid using traits at all just feels like a better thing to do, but harms flexibility.
A better vision of the new syntax is trait_object::Self::associated_function(). Because Self is a keyword, the trait can never declare an associated type named Self, meaning that a new edition of Rust is not even required, and this change can reach stable even in Rust 2015, let alone 2018 and the proposed 2021. This also feels more concise and readable, speaking for itself ("dispatch the actual type of trait_object using vtables and invoke its associated function"). Same thing for associated constants, they just need to reside in the vtable too. (A more problematic question is, though, how complex would that be in terms of implementation, since that'd require modifying the vtable format. We don't have ABI stability, but just stuffing constants into vtables could require editing the part responsible for finding function pointers in vtables, since then it'd mess up the assumption that all fields in a vtable have the same size, which is not guaranteed by any kind of alignment rule, since constants can be bigger than a pointer.)