If I fully specify the generic parameter on both From and Vec Storage<T>, then I should be able to call from no matter what, but in your case there are still additional choices to make. Perhaps you should use a generic function instead of a trait?
The impl header must constrain all type parameters.
// \/ header starts here
impl<T: Vector, U: El, I: OEl> From<&str> for VecStorage<T> { ... }
This doesn't even mention U or I in the header, so they are unconstrained.
Some examples,
impl<T> Foo<T> for Bar { ... }
impl<T> Foo for Bar<T> { ... }
impl<T, U> Foo for Bar<T> where T: Yam<Rat = U> { ... }
all of these constrain T and U
In the last one, U is constrained because of the following deductions
U is an associated type on a trait constraint on T
T is constrained
So no matter what choice of T you have, there will only be 1 choice of U.
Note: the following do not constrain T
impl<T> Foo for Bar { ... }
impl<T, U> Foo for Bar<U> where U: Yam<T> { ... }
With the last one, U could implement Yam<_> with multiple different type parameters, so we don't have a guaranteed single way to constrain what T could be.
Fundamentally the problem is that for each choice of T the type VecStorage<T> may only implement the trait From<&str> once, however it will implement that trait several times: one time per choice of U.
Note that the T: Vector<Vec<Option<U>>> constraint does not save you. There's nothing saying that T couldn't implement Vector<Vec<Option<i32>>> and Vector<Vec<Option<String>>> at the same time. (you need associated types for that)