User Input in WYSIWYG Editor is lost after conversion error

If a conversion error in the HTMLConverter happens while saving content
from the HTMLEditor, the user is redirected to the editor and an error
message is shown, as expected. However the latest edits to the content are lost.
Instead the contents from the last successful save are shown, but in
plain wiki syntax instead of html.

What seems to happen:
When the HTMLConverter - called from the DefaultXMLFilter - creates an error, the Filter stores the error and the user submitted data in two session variables "com.xpn.xwiki.wysiwyg.server.converter.errors" and
"com.xpn.xwiki.wysiwyg.server.converter.output" respectively.

The content then should be redisplayed from the information stored in the session in the wysiwyg editor, as it has
happened in the macros.vm, #macro(wysiwyg_input ...)
Hwoever this macro has been scrapped in commit
753000ec27d4a0ca9259c3f63112536065ea841d and (as least so it seems to me) this functionality has never been restored elsewhere.

The error rendering macro wysiwyg_displayConversionError properly discovers the error from the session, and beside of rendering an error message it also sets 'convertInput' to false, but as the input is not updated to the latest tried-to-save-as-html content, the currently saved wiki-syntax content is shown in raw wiki syntax.

Steps to reproduce: hm, tricky.
Unlike some of our users, I have a hard time producing any conversion
errors via the wysiwyg editor. the only way I figured to force a conversion error is to remove a "startwiki:" marker from some comment around a wiki link (via Firebug). Afterwards pressing e.g. the "Preview" or "Save & View" button triggers the behaviour.