The "." at the end also serves another level of defense. When you provide a URL without a . at the end, I can append .someotherdomain.com. and redirect traffic. And I've seen that in the wild before.
And the difference between "pedantic" and "technically correct" is how you get hacked. But feel free to throw insults. I know one of us is right, and it aint you.
No one (within a rounding error of 0%) will change how they enter, use, or program systems to work with, URLs to use the FQDN. The incompatibility nightmare it would cause would be insurmountable.
So I don’t think pointing out the technicality of how a domain name is supposed to be represented really helps in this context.
This document clearly says that the dotless form is perfectly acceptable and even expected.
Take for example this snippet:
Relative names are either taken relative to a well known origin, or to a
list of domains used as a search list. Relative names appear mostly at
the user interface, where their interpretation varies from
implementation to implementation, and in master files, where they are
relative to a single origin domain name. The most common interpretation
uses the root "." as either the single origin or as one of the members
of the search list, so a multi-label relative name is often one where
the trailing dot has been omitted to save typing.
Which says that relative names are meant to be used in user interface (ie by humans) and the most common interpretation of a dotless name is to be in the global/root namespace.So yes, the dotless notation comes down to own we interpret domain names. However that interpretation is not a mistake, it is expected.