First off, fn(&mut self) -> Value is a lot less uncommon than you're implying. Plus, shared mutability completely breaks the dichotomy that you're trying to make more visible.
Also, since this is just a large syntax change with high cost and high likelihood of dialecting the language, its chance of passing RFC is very low. (Again, I'll encourage you to pursue other avenues for exploring the syntax, but asking Rust developers to do it on a production language isn't likely to get you far.)
Existing edition changes did require some changes, and requiring dyn Trait for trait objects was probably the most disruptive one of them. If your change is more onerous to existing codebases than dyn Trait was, then it's probably never making it into rustc.
Your vision is interesting, don't get me wrong! But it isn't Rust; it's a very different language (potentially on the same abstract machine) with different ideals on the frontend. For better or for worse, Rust cares about being relatively approachable syntax-wise to people familiar with C family languages. If I'm not mistaken, identifier adjacency is only ever used in any semi-mainstream C family language where one token is a keyword (or positional keyword).
And this is actually a very valuable property! It means that keyword adjacency is "negative space" in the language design that does two things: it makes it stick out as significant and meaningful, and it gives us the possibility of adding new positional keywords.
I want to note that x.get() and x.set() use the same syntax, because they are the same thing – sugar for X::get(#autoref x) and X::set(#autoref x). Method syntax is a bit special since it's the only way to get autoref behavior where a place is automatically referenced exactly as necessary, but otherwise it's just a normal function call. There's no conceptual difference between an "action" and a "query".
Rust isn't OOP, and the "method" isn't special. It's all just functions, to the point that while we currently have Unified Function Call Syntax (UFCS) that allows calling methods as the functions they are (Type::method(&receiver)), there's a repeating and loosely positive push towards eventually accepting Unified Method Call Syntax (UMCS) that allows calling arbitrary potentially free functions as methods (receiver.crate::function()).