I'm not sure what you mean about the obligation to drop. `MaybeOwned` exists to avoid unnecessary allocation/copying when the function is able to return a slice with a specified lifetime instead (either `'static`, as is common, or borrowing the receiver). This is largely just an optimization, but it's a good one because unnecessary allocation sucks.

I do understand your comments about the issues surrounding implementing a correct DST-aware `MaybeOwnedVector`. Personally, I think it should just have `&[T]` and `Vec<T>`, because I think `~[T]` is largely useless now, although I expect that supporting `~[T]` would impose very little additional complexity (the API of `MaybeOwnedVector` wouldn't change, it's just one more small impl, and perhaps a second if we have an `IntoMaybeOwnedVector` trait just like we have `str::IntoMaybeOwned`). Really the biggest issue I can think of is naming. `str::MaybeOwned` has `Slice` and `Owned`, so maybe we can use those and use `Growable` for `Vec<T>`.

Also, as I understand it, we should be able to use `#[experimental]` to annotate the enum even if it's in `std::vec`, although I'm not certain where we ended up on the topic of having less-stable items inside more-stable items (e.g. `#[experimental]` item inside a `#[stable]` module).