The more realistic approach would be to define something like sodipodi as viewer
for svg+xml files, since it is a real vector graphic program. Eog can handle
only rasterimages, which are completely different. The GdkPixbuf library though,
allows us to load a SVG image as an bitmap/raster image that eog can display.
During this process the whole information/structure of the vector image gets
lost, making saving as SVG nearly impossible.

If someone want to take a look into this and see if this can be hacked into
GdkPixbuf anyway, go ahead. The sources are in gkt+/gdk-pixbuf. An extension of
the svg loader module would be required, to allow saving too. If the module
declares a svg saving method, than this will be used by eog with no changes.

This seems to work now, though I can't find what fixed it.

Maybe there is an update of the GTK pixbuf svg module now. Haven't checked yet.

Jens:

Isn't this function now handled by eog_image_copy_file() and such in eog-
image.c? The pixbuf loaders are probably better off not being adjusted to 
handle this anyway... even though it would make an upcoming SVG feature in 
other apps I work with much, much easier to implment.

As far as testing goes, using eog 2.7.1, 'eog http://mydomain/bah.svg' , Save 
As, changing to a logal folder, then finalizing the save seems to work fine. 
I've got librsvg's mozilla plugin installed, so I'm not sure if I can test it 
quite to the extent needed.

Ah, ok. Haven't thought of the most simple case :). Indeed, if you now 'Save As'
an otherwise unmodified file under the same file type, the file is simply copied
1:1. This won't work if you modify the image somehow (like rotating). 

Removing "Save As" capability is part of 2.14 plans. See bug #320893 to keep
track of this subject. This is a WONTFIX bug.