My interpretation of the Unicode standard (version 5.1) as it applies to U+00AD occurring within the content of a <text> or <tspan> element is that U+00AD is for indicating possible break points, but <text> and <tspan> in SVG never do line wrapping, so U+00AD should always be invisible and non-advancing when it occurs in the content of <text> or <tspan>.
I believe that the behaviour of rendering each U+00AD character as an (english) hyphen glyph is from Unicode versions prior to 4.0, when U+00AD was changed from a dash (Pd) to an ignorable formatting character (Cf).
In other words, I believe that Inkscape's existing behaviour is correct for <text> and <tspan>.
I should say that this is based primarily on UAX#14 ยง5.4 (http://www.unicode.org/unicode/reports/tr14/#SoftHyphen), perhaps supplemented by Unicode FAQ entry http://www.unicode.org/faq/unsup_char.html#3.
If <flowRoot> were part of SVG, or if we were to change our representation of flowed text to either <textArea> or <foreignObject> of xhtml, then I believe that the appropriate behaviour is as per the aforementioned http://www.unicode.org/unicode/reports/tr14/#SoftHyphen, i.e. that the appropriate rendering should depend on "the word and the language".
For the moment, I won't say much about what test to use to determine which hyphenation behaviour to use (Malayalam vs English vs Arabic etc.); though the approach I've used in other text-rendering software is to pretty much ignore xml:lang, instead looking at the script (g_unichar_get_script) of the character preceding the U+00AD (skipping any characters that give G_UNICODE_SCRIPT_INHERITED). If there is no such previous character on the same line, or if the script is one of the many for which I don't know the correct behaviour, then I don't add a glyph. (This actually seems to be the right behaviour for most scripts, and is also technically correct in terms of the above-referenced FAQ entry.)
pjrm.