From reading the spec, the problem with SVG is that it is very difficult to implement completely due to the all-encompassing rendering model, javascript integration and animation scripting. This makes it difficult to read and write, without pulling in half a browser, and next to impossible to edit fully, unless using a text editor.
So if we do see more adoptions, it's quite likely they'll either end up incompatible with each other or some consensus on a work-able subset of SVG is reached.
Perhaps if W3C had done a reference implementation much like, say, H.264 has reference implementations, some of this could have been avoided?
I'd enjoy reading opposing views on this, interesting topic.
http://www.w3.org/Amaya/ is a kind of reference browser from the W3C. The release history lists the first SVG support in Amaya 4.0 from 10 November, 2000.
Amaya does not render correctly the most basic SVG files. Even IE6 would make a better reference implementation of web standards.
Batik seems to be the most well-tested and conformant implementation of SVG at the moment: http://xmlgraphics.apache.org/batik/status.html, though I would use WebKit as reference because of it's market share and potential of Google and Apple to change the SVG spec.
So if we do see more adoptions, it's quite likely they'll either end up incompatible with each other or some consensus on a work-able subset of SVG is reached.
Perhaps if W3C had done a reference implementation much like, say, H.264 has reference implementations, some of this could have been avoided?
I'd enjoy reading opposing views on this, interesting topic.