Well, this is actually the idea behind it. There is an internal object model, but currently the mapping from SVG to the internal model is almost 1:1. One first exception is clip paths, which in Hyvector is a path with stroke and fill and a content that is clipped outside that path. In SVG handling of clip paths is quite cumbersome and not very intuitive.
If I can continue developing this other features will follow: Corner rounding of paths, non-destructive boolean operations, variable stroke widths, multiple fills, distortions, etc.
The thing is that I want to keep SVG as the export format, because it it really good for the wbe can be styled with CSS. Therefore effects must be exportable as true SVG (even if composed of multiple SVG elements), not some fake bitmap inserted into an SVG as some other editors do it when exporting SVGs. This for example means that there will be no conic gradients unless they are supported by SVG one day.
> In SVG handling of clip paths is quite cumbersome and not very intuitive.
Modern web browsers now support "clip-path" CSS property with inline/shorthand values which are much more convenient to use than <clipPath> element. There are some examples on MDN [1]. I haven't performed extensive tests yet but they seem to be working just fine with SVG objects.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/clip-path