Can you summarize what you think the spec should say and, if you have time to figure it out, how that would differ from what is implemented in Blink today? There are no use counters for these methods, but I could add some if there's any non-trivial change suggested.

Aditional bugs from Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=312019
https://bugzilla.mozilla.org/show_bug.cgi?id=505178

BTW, this example https://bugzilla.mozilla.org/show_bug.cgi?id=312019#c17 still was not correct, so Firefox behaviour is opposite to IE and Chrome behaviour even in such small things.

Old algorithms for this methods from DOM3:
http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html
New DOM is more simple and some other stuff which operate on namespace was kicked (like Document.normalizeDocument):
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-normalizeDocument

To be honest I have no idea what you can do with it. I never use this methods so try find some other usage cases but without satisfactory results. Most libraries for DOM don't use them, all other examples try operate on namespace:element by other way (iterate and directly checking element/attr properties, using CSS selector, etc.).

I try figure out how they are implemented in browesers, but realy, this was the worst in all DOM. I get different result in all browsers for HTML, when testing *XML (via DOMImplementation) get another differences, even for innerHTML:) I guess that because we have these differences no one uses these methods.

Maybe Jonas Sicking or Henri Sivonen (via https://bugzilla.mozilla.org/show_bug.cgi?id=505178#c10) could suggest some practical applications for them if they must stay in new DOM spec. Are there any data on their usage?

And of course remember that this methods came from Node, so again may be a potential problem for Attr, because they jump to owner Element (if exist), and who knows if devs don't use them directly in attributes. Currently all browsers still have them for Attr.

There aren't any use counters for these in Blink, but I had a look in the 20150101 httparchive dump, and the regex 'lookupPrefix|lookupNamespaceURI|isDefaultNamespace' only matches in 453 of 10139623 resources, which is ~0.0045~. Still, given how old these APIs are, I don't think that's low enough to just remove them, but it does mean we don't need to worry a lot about edge cases.

Testing <http://w3c-test.org/dom/nodes/Node-lookupNamespaceURI.html> in Firefox, Chrome, and IE 11 shows that all fail a number of tests, but there's no single test that all three fail.  This suggests that the current spec is probably good enough to implement, given the marginal use of the feature.

(All three browsers pass all the lookupPrefix tests.  I didn't check to see how thorough the tests are or inspect Gecko source code to see whether we deviate significantly from the spec.)

Aryeh Gregor check this:

<script>

	var newDiv = document.createElementNS("www.test.com", "ns:div");
	var newTest = document.createElementNS("www.test.com", "test");
	var newP = document.createElement("p");

	newDiv.appendChild(newTest);
	newDiv.appendChild(newP);


	console.log(newDiv.namespaceURI + " | " + newDiv.prefix); // www.test.pl | ns
	console.log(newTest.namespaceURI  + " | " + newTest.prefix); // www.test.pl | null
	console.log(newP.namespaceURI  + " | " + newP.prefix); // http://www.w3.org/1999/xhtml | null

	console.log(newDiv.lookupPrefix("www.test.com")); // ns
	console.log(newTest.lookupPrefix("www.test.com")); // ns
	console.log(newP.lookupPrefix("www.test.com")); // ns

</script>

Chrome: ns, ns, ns << per DOM this looks correct
Firefox: null, null, null
IE and Presto: ns, null, ns

"This suggests that the current spec is probably good enough to implement, given the marginal use of the feature." << yep, if finally some engine implements all of these guidelines, then changes in the spec will not necessarily.

The spec seems fine, although browsers are not yet interoperable.  Reopen if there's a specific change you'd like in the spec (or, better, file a GitHub issue).