Right - caller of add gives up ownership. It seems like that's what you want since you have a Vec<S> rather than a Vec<&S>? In other words, do you want the Vec to own the S's or borrow them (i.e. hold references to them)?
It was originally meant to determine the best way to add structures to vector, in the following context:
a struct A reads an XML file and create some other structures struct S from XML data
and push those structures into a vector (field of A)
Afterwards, I thought it should be useful to make this add function generic, to allow any struct to be added to a vector. But it seems in Rust, the overall context is important (whether or not relinquish ownership)
Right - whether a vector owns the values or holds references to values or holds something like Rc (and thus shares ownership) are all important.
In your description above, it would seem like you'd want the vector to hold the parsed data (S values) and then other code can use that vector to borrow these values if needed.
Another detail with knowing in this case is, is S large? If not, then you may want to just copy the data, so that no transfer of ownership needs to occur.
If you derive the Copy trait then it will be automatically copied when used by value (like primitive types are).
Also on that page you can see the Clone trait, which is for explicit copies. If you #[derive(Clone)] (which almost all types should) then x.clone() creates a copy.