I think that's what you would expect. Why do you think it is strange?

I don't know, I just find the concept of lexicographically ordering vectors something that isn't really useful. Can you think of examples where this might be something you would want?

Obviously you need a PartialOrd (and Ord, PartialEq and Eq) implementation for all fundamental data structures, since otherwise they are unusable (can't sort to canonicalize ordering, sort+uniq, use as btree keys, etc.).

Lexicographic order is the most common choice for vector; the other reasonable choice is length-then-lexicographic.

The alternative I'm suggesting is that it is not implemented at all.

If you ever create a BTreeSet<String>, it will use String's PartialOrd, which is directly #[derive]d from Vec<u8>.

I have nothing against String having PartialOrd. I don't see why this means Vec<u8> should be PartialOrd–especially because treating a String as a Vec<u8> sounds very wrong.

Why does it sound wrong? Since strings are UTF-8, this just boils down to lexicographical ordering of code points.

Ironically though, that should be actually more objectionable than ordering arrays by lexicographical order of elements, because the underlying code point order is pretty much useless for any other purpose than having some arbitrary deterministic order. Meaningfully ordering strings is an inherently locale-dependent operation, and PartialOrd has no way to take this into account.

Maybe not specifically for vectors as their size is dynamic, but most certainly for tuples, ex. "sort by last name, first name, city..."

(I can also think of situations where you'd pass around strings as vectors of characters, but I think that's a bit of a stretch.)

Yes, if your vector represents indices into a tensor for example. I have written code that does exactly that in C++.