In your opinion:

1) Is it good style to generalize the word `cons` to cover more types
    besides linked lists (yielding vector-cons, string-cons,
    hash-table-cons, etc.)?

2) Is `cons-right` a reasonable name for an operation that adds one
    element to the end of a proper list or other sequence, or does the
    name amount to an abuse of the concept of consing?

As prior art, Haskell has extended cons to cover many types
(https://hoogle.haskell.org/?hoogle=cons). Regrettably, instead of
giving the reverse operating a clear name like `cons-right`, Haskell
has adopted the backwards written word `snoc` in the tradition of Unix
shell and the like (shell has `fi` and `esac` to close `if` and
`case`, respectively).

The case for a `cons-right` operation in statically typed functional
languages is simplified by the fact that these languages don't have
improper lists, so `cons-right` is a proper mirror image of `cons` in
all respects except computational complexity.

As prior art for the name `cons-right`, SRFI 1 defines these
procedures:

take-right
drop-right
fold-right
unfold-right
pair-fold-right
reduce-right

SRFI 13 defines:

string-take-right
string-drop-right
string-pad-right
string-trim-right
string-index-right
string-skip-right
string-fold-right
string-unfold-right

R6RS defines:

fold-right
fxarithmetic-shift-right
bitwise-arithmetic-shift-right