If we want to change that behavior, we first should all know why we have it in the first place. There is some nice history on StackOverflow: https://retrocomputing.stackexchange.com/a/10858

To me, it looks like -> has been introduced as a feature which in this way is (usually) not used anymore. I do think that C does not need the distinction between . and -> anymore. (But, it certainly needs to stay compatible with C++.) Most modern languages don‘t have -> if I‘m not mistaken (Rust, Zig, even Java).

I think that it is important that C++‘s smart pointers behave the same way as built-in pointers. However, this does not necessarily mean that we need to drop this idea. Instead we can revisit the operator. proposals. These also have suggestions how to distinguish between member access to the outer or inner class. If we have this distinction in place we can allow . instead of -> on pointers and also resolve operator-> according to the same rules we can apply to operator. . We could also just steal the ideas of operator. to distinguish between inner and outer member without allowing operator. (it might not be necessary after all if . automatically rewrites to operator->). The question is if it makes sense to get rid of a->b just to introduce something like a..b (.. is one of the suggestions to resolve ambiguities). It would hurt teachability, though, if we don‘t introduce operator. along the way and you have to write operator-> instead to actually get operator. behavior. That would be really confusing when nobody still knows the old -> syntax.

In short: If we allow a.b instead of a->b we should also introduce operator. to make it consistent for user-defined types.