So, if the implementation of your ImVec is like that and you're not modifying, then there's really no point to having it. I'm sure there's a more correct way to write this (this can only modify a preexisting Rc<Vec<T>> and it can't update another ImVec<T>). If you're writing as well and you've got an O(log n) situation vs O(1) & O(n) situation then I'd say it depends on what the specific case is; if you're cloning frequently then Rc makes sense, otherwise ImVec.
Iteration over im::Vector<T> is amortized O(1), while iteration over Vec<T> is O(1) (without amortization costs). Random lookups are O(log(n)) vs O(1) over the same types.
Rc<Vec<T>> allows immutably sharing Vec<T>, and should generally perform better.
edit: To clarify, iterating either data structure is O(n); I was referring specifically to the time complexity of the individual Iter::next() implementations.
I was going to make the counter argument that assuming the interior nodes are "32 wide", for a vec with 1B elements, log(n) is only ~6.
But then I realized: for a plain Vec, to access v[i], we can jump directly to where the element is located. However, with ImVec[i], we may have to to 6 "sequential, randomish memory lookups" to figure out where to jump to -- and this this can be quite a slowdown.