> Do they really care to see* if they are at www.site.com or m.site.com or site.com or do they just want to know they are at site.com
www.example.com == example.com is an assumption that has never been true and I have seen it screw over regular users countless times. Quietly rewriting the URL and hiding that fact will just make that worse.
As for m.example.com, that is even further from standardized. Me and and at least one person I know have personal websites with short aliases like mike.lastname.tld == m.lastname.tld, not to mention the plethora of sites that don't have matching paths on mobile vs desktop. Even if copying the URL quietly switches it out for the real one (which is bad on its own), that break the surprisingly common workflow of writing down the URL you see on a piece of paper.
Thank you for talking about a real use case :). The m. causing a new workflow issue to be introduced is exactly why they decided "m." should not be treated as a trivial subdomain when they rolled it out, it was only that way during testing.
As you said www.example.com being functionally different from example.com was already a broken workflow, users weren't differentiating it. Continuing to display something users haven't understood for 20 years was not considered a strong enough reason to simplify the URL display now in a way that causes the same errors users were commonly making anyways.
