One thing about creating new features for a product such a browser is the features they are almost always designed and implemented in such a way that is convenient for the creator of a product but not for anyone else (this isn't intentionally done though). The proprietary features of browsers are designed to fit the architecture of the browser so that they can implemented as quickly and easily as possible. They don't go through months of years of iteration like standards do.
If you look closely at some of the documentation of CSS or scripting features of browsers, you will find numerous design decisions that seem odd. This is not because the designers were stupid, but because architectural issues prevented the designers from creating something more sensible.
The IE documentation refers to numerous things that really seem to be only there because some part of its architecture requires it. No other browser would have a need for such features. IE's way of displaying unstyled XML as a 'fancy tree' was fine for it, but since Mozilla can render styled XML directly, that feature took some time to work out how best to implement it, without breaking XML that was supposed to be displayed styled.
Some people have complained that with XBL, one has to add various tags to describe properties and methods, rather than just using a script file with functions in it. While that may seem easier for the XBL author, there may be implementation details that make it harder to handle. What I mean is that given a specific browser architecture, it's possible that a separate script would be difficult for the browser implementor to deal with.
A good example would be the innerHTML property of elements. While this may seem like a convenient way to change the content, it adds a dependency of an HTML parser to the DOM module. And not only an HTML parser, but one that can parse a fragment, not just a document. While this may not seem like such a concern for a browser, it today's world of componentized systems, there may be a product which has licensed a pre-built HTML or XML parser, or may be using a standard parsing library. Since many languages often include an HTML or XML parsing module, developers would tend to just use that. Since the developer doesn't necessarily have the option of changing the parser, if it doesn't provide any hook to handle the innerHTML property, it really isn't possible to include such as feature.
So, don't assume that a feature found in one product is necessarily implementable in another. The standards go through several iterations with comments from many people or groups, in order to ensure that they are the most implementable in the most cases. Propreitary features don't.