bug#33998: 27.0.50; cl-delete does not delete the first list element

[Drew Adams]

> > Without setting variable `seq' (i.e., without
> > the `setq'), that variable is still bound to
> > whatever it was bound to prior to your invoking
> > `(cl-delete thing seq)'.  Presumably it was
> > bound to a cons.
> 
> It could have been bound to a vector. cl-delete (as delq, delete)
> accepts sequences. And contrary to those two, it makes
> no guarantees as to how it potentially destroys the original
> sequence. So unless you're relying on a particular
> implementation, relying on SEQ after calling cl-delete on it
> is a bad, bad idea.
> 
> So yes, always (setq SEQ (cl-delete THING SEQ)).  With
> the extraordinary exception that you're leaving the scope
> where SEQ is visible.  Then you can bypass it.

I'm repeating myself, so I'll stop here.

You are _not_ "calling cl-delete on it", where "it"
is the variable SEQ.  You are calling the function
on its value, whether that value is a vector, a
list or any other kind of sequence.  `cl-delete'
never sees, smells, or hears the variable.

It all depends what a user intends by "relying on
SEQ".  If you ALWAYS mean relying on its value to
be what `cl-delete' returns then sure, clearly you
must ALWAYS set it to that return value.  If in
some case you instead mean relying on it not to be
affected by `cl-delete' then you won't want to
assign it to the result of invoking `cl-delete'.

It's not about implementation of `cl-delete'. It's
not about the type of sequence you pass it.  It's
about a variable being something different from its
value.