This is as designed. It adds flexibility. I agree that it may feel a bit strange at first but I don't want to remove this capability. If only because other programs may create SVG with text thus moved from its path, and we must be able to view and edit these files.
It does feel strange, and I agree that it's nice to have but then you should be able to move the path as well without moving the text.
This is only possible via a mechanism similar to the one used for clones to stay put when their original moves. This is quite a bit of additional code, and I'm not convinced that it's really that necessary. Anyone else has an opinion?
I don't think this is really necessary. If your path is invisible, you can still select it by selecting the text attached to it and pressing Shift+D (same key as for finding a clone's original).
True, didn't even know, since I'm not using clones really. But since _I_ didn't know, using inkscape quite a bit, I feel that for this part the path should be some color... or inverted or what ever when the text is selected.
It even shows a tip on Shift+D in the statusbar. As for highlighting paths, maybe, but we don't have infrastructure for that currently. It's a lot of work to make this possible.
This could generally be done for paths without outline, when they are selected, id doesn't have to though, since usually you don't have invisible paths with no filling.
You can switch on the bbox selection cue in prefs and this will give you at least a box for an invisible path.
I haven't looked into that yet, but I think I agree; whether this is easy/possible to implement in SVG is another matter. SVG textpath has one feature that really drives me mad: when a text is too long for its path, the spec says that the rest of the text must not be shown! (Instead of e.g. continuing along the direction of the last path segment.) I think this is really stupid and ugly, but we must obey if we are to be compliant.
That _is_ quite stupid... is there a possibility to file a bug against the specs?
Probably. I don't know how, though.
well, it doesn't really give you the desired effect because you have to do all the horizontal kerning manually... (all the letters and a being chuncked together and spread apart) basically the feature should put the text onto an outset path of the original path.
What prevents you from making a linked offset of the original path, outsetting it, and putting text to it? I.e. every component of what you need is there, you just need to combine them for your purposes.
Generally, I prefer to not make "compound" commands like this (unless the advantages are too high to ignore), because this just clutters the interface, often requires ugly hacks and special cases in code, and makes _understanding_ the interface more difficult. I think the program should provide a set of well-thought-out building blocks, so you are free to use them in any combinations you want.