The order of kons in vector-fold / @vector-fold is the same as R6RS fold-left.
In a retrospect, vector-fold-left and @vector-fold-left would've been a better choice.
SRFI 1 established the precedent that we don't use "-left" as part of fold, and SRFI 13 extended that to trim and pad. Left is a natural default for folding in an eager languages, as right is a natural default in a lazy language.
Now that srfi-133 is (scheme vector), so it would be difficult to change. It isn't desirable
that srfi-160 and srfi-133 deviate. I'm not sure how to solve this. At least, if there
would be another chance, I like it to be adjusted for the consistency.
It was already beyond fixing when 133 was first created, because it would have produced a subtle incompatibility between 43 and 133. The other incompatibilities involved the *number* of arguments passed to procedure arguments and would have failed noisily, whereas a problem with the *order* of arguments would often be silent. To make things worse, many fold examples are commutative, in which case it doesn't matter.
I think we have to live with the list and string SRFIs (Olin Shivers's group) being incompatible in order with the vector SRFIs (Taylor Campbell's group), and just maintain compatibility within each group.
I've just sent an email to Taylor to ask if he remembers why the discrepancy.