T is Number, and T: From<u8>
// the type implementing what the method slice_index get
1. Self: Vec<T> -> &[T]
2. Self: Vec<Vec<T>> -> Vec<&[T]>
3. Self: Vec<&[T]> -> Vec<&[T]>
Since the return type borrows, you're going to need a GAT or you're going to need to put a lifetime on your trait, so that you can weave a lifetime from &self to the return type.
Let's set that aside for the moment though, and consider the generic implementations, and what concrete implementations end up being applicable (existing) for the example types.
// Implementations
impl<X> RowIndex<...> for Vec<X> // returns &[X]
impl<Y> RowIndex<...> for Vec<Vec<Y>> // returns Vec<&[Y]>
impl<Z> RowIndex<...> for Vec<&[Z]> // returns Vec<&[Z]>
Vec::<i32>::slice_index returns...
X = i32: it returns &[i32] (via impl #1)
i32 can't unify with Vec<_> so impl #2 does not apply
i32 can't unify with &_ so impl #3 does not apply
Vec::<Vec<i32>>::slice_index returns...
X = Vec<i32>: it returns &[Vec<i32>] (via impl #1)
Y = i32: It returns Vec<&[i32]> (via impl #2)
Vec<i32> can't unify with &_ so impl #3 does not apply
Vec::<&[i32]>::slice_index returns...
X = &[i32]: It returns &[&[i32]] (via impl #1)
&[i32] can't unify with Vec<_> so impl #2 does not apply
Z = i32: it returns Vec<&[i32]> (via impl #3)
So, unless you do something to prevent the implementations from overlapping, the method calls may be ambiguous for the latter two. If the type of the output is unambiguous in the context of the method call, this might not be a problem.