If the question is "should we push other renderers to change their rendering of soft hyphen inside a flowRoot", then I believe the question reduces to "should we push Batik to change its rendering of soft hyphen inside a flowRoot". For other renderers, any push would be in the form of contributing to SVG 1.2 Full, and I believe the working group aren't looking at that until SVG 1.2 Mobile has progressed.
(As for Batik, I gather that there's very little active development, though we could probably get it in if we were to write the patch ourselves.)
If the question is "should we push other renderers to change their rendering of soft hyphen in <text>/<tspan>, and change in what way", then we might first ask how Inkscape should handle hyphenation when converting a flowRoot to a <text> of <tspan>'s. I suspect that the practical answer is that we would generate tspans that contain the actual text we want rendered, including any respelling and whatever hyphen glyphs we think are appropriate for the language/script.
If we want to recover the original unflowed text (to allow subsequent editing within Inkscape, for example), the easiest option for us is to retain the whole flowRoot (whether in an inkscape-namespace element, or inside a <switch> as a sibling to the <text>). This also allows recovering forced line breaks from the original text.
If instead we introduce a special attribute to recover line breaks and respellings, then we might as well use that same mechanism to recover original hyphenation.
pjrm.