Also, it happens while copying and pasting objects with shadows.

Yes, they also get removed using the 'convert' -> 'paint layer' on the vector layer. 
What I did for my current project is to hide all other layers ; select all , copy visible , and save a baked result ( pixel ) of them. Text loose his dynamic quality this way , but better than nothing. :-)

Warning, big block of text ahead.

I've been doing some research on the subject.

The main problem is that the artistic text shapes are not treated as normal text with a certain style, but as embedded svg files in the document. Also, the copy and paste is done using the ODF descriptions of the copy elements, instead of direct copy those elements (in a copy constructor way, for example) and then deal with the target format details when the file is saved or exported. So those hard to implement features (maybe not yet implemented) or the not directly supported features by the ODF format (and svg format) are lost wathever you perform any of this operations :-(

The svg file contains the actual text, the font type (although if you do not apply any specific type is set by default to "ComicSans", which is another bug in my opinion), fill color, stroke line type... but no shadow nor its attributes. Svg has no way of expressing object's shadow as an attribute of the object itself. However, you can generate the object's shadow using a chain of filters. For example, this code defines a rectangle with a semitransparent red color blurred shadow:

<svg height="140" width="140">
  <defs>
    <filter id="dropshadow" x="0" y="0" width="200%" height="200%">
      <feFlood result="shadowcolor" flood-color="#ff0000" flood-opacity="0.5" />
      <feOffset in="SourceAlpha" result="offsetalpha" dx="20" dy="20" />
      <feGaussianBlur in="offsetalpha" result="shadow" stdDeviation="1" />
      <feComposite in="shadowcolor" in2="shadow" result="coloredshadow" operator="in" />
      <feMerge>
         <feMergeNode in="coloredshadow" />
         <feMergeNode in="SourceGraphic"/>
      </feMerge>
    </filter>
  </defs>
  <rect width="90" height="90" stroke="green" stroke-width="1" fill="yellow" filter="url(#dropshadow)" />
</svg>

The tricky part of using svg filters is to calculate the size of the region in which the filter is applied (the x, y, width and height attributes of filter element). Recall that we have as inputs the shadow distance and the blur factor. When those inputs grow up, we need to expand the filter area too, so the resulting svg object should be larger to allow us to display the whole shadow (recalculating the width and height attributes of the svg element). In the same way, the size of the calligra shape object should be changed in the same way to allow us to draw the svg completely.

And here's the problem: if you implement this in the svg way (if it is possible to implement the whole thing), the configuration and the use of shadows in artistic text shapes types will not be consistent anymore with the others calligra shapes types, plus the resulting shadows may not be drawn in the same manner.

I am not yet too confident to all of the Calligra codebase and the desing decisions taken to write it, but i think that the distinction of two separate ways to create and manage text shapes (artistic text and multiline text) brings this type of things as a result. Maybe the best way of get rid of all this nasty behaviours are to redesing and unify the shape text tools (?).

Hi Juan,

Yes... We really should start thinking about the text tool in Krita. Well, about the vector support as a whole. As you say, currently, it's based on ODF with embedded SVG. I think that it should be possible to use just SVG for our vector layers, but that means quite a lot of work. Inkscape shows that it's possible to do all kinds of fancy stuff in svg, and sometimes I wonder whether it wouldn't be better to shell out to inkscape when editing a vector layer...

Resolving all text tool bugs as Later, since the text tool will no longer be developed, but replaced.

We just merged the new text tool.