I'm not suggesting that DNSSEC validation can't be part of a browser; I'm suggesting that it isn't part of a browser, or part of virtually any other computer program that uses the DNS. Tens of thousands of programs have been built to variants of the BSD socket interface, none of which automatically admit to DNSSEC. You could just as easily suggest that we'll all have IPv6 support, just as soon as every piece of software that assumes an IP address is 4 bytes long gets updated.

But it's actually worse than IPv6, because all IPv6 does (as far as a socket program is concerned) is make IP addresses bigger. DNSSEC requires the application to implement a new state machine to handle the case where validation of a name fails, and implement the UI to handle the user's input to that state machine.

Also, I object to the notion that end-system DNSSEC validation is "the ultimate expression of DNSSEC". No; the IETF spent years trying to standardize alternatives to end-systems doing DNSSEC (like TSIG), and many of the same standards people objected to the idea of end-systems implementing full recursive resolvers (load on the roots, etc). It's only when the "last mile" of DNSSEC comes under scrutiny that they suddenly decide we should all be running full caches after all.

(gethostbyname, getaddrinfo, same problem; like I said, you might just as productively offer failure/alternative information over HTTP REST, because getting that information into real-world programs requires significant code changes no matter what).