[mindslight]

DNS names already conflict with v4 addresses, and we deal with that ambiguity just fine.

For an actual conflict, someone would need to be using hostnames that had at least 16 segments, none of which were longer than 4 characters. Putting the burden on someone who wants to use extremely deep hostnames that look like bare IP addresses to type a trailing . on their hostname seems plenty reasonable to me. And if they want to use resolv.conf:search while still typing in 16 segments of a hostname, then that ambiguity could be resolved with a leading period.

I suspect the real reason is people who wanted to be able to write ad-hoc parsers using strchr().

[Dagger2]

We deal with it by requiring v4 addresses to be entirely numeric, which... well, it's possible for v6 but would make it even more annoying to type v6 addresses out.

[mindslight]

No, that is not how it is dealt with. A DNS hostname can be entirely numeric as well. For example, add 'search in-addr.arpa' to your resolv.conf.

We deal with the ambiguity by making it clear that if you expect to use DNS names that look like IPv4 addresses, you're going to experience the pain of unexpected behavior. I see no reason this general expectation couldn't also have been set for 16-segment hostnames that look like hexadecimal IP addresses.

Alternatively, a full IPv6 address without any '..' abbreviation could have been defined to start with a period. Then there would be no ambiguity.